Tag: ICE

  • ICE Controversy May Lead to IT Contract Chaos

    ICE Controversy May Lead to IT Contract Chaos

    For as long as most IT professionals remember, the only political issues any IT organization considered were largely internal. However, that appears to have changed in 2019 as more IT professionals begin to question whether they want to do business with IT vendors that support an organization they staunchly oppose on moral grounds.

    This week that very drama is playing out in the form of a reversal after Chef CEO Barry Christ announced the provider of IT automation software would no longer provide support for its software to the Immigration and Customs Enforcement (ICE) agency, which is enforcing immigration policies enacted by the Trump administration.

    The issue came to a head when Seth Vargo, a contributor to the open source Chef repository, decided to remove what many consider to be a critical module of code he contributed to the community to protest a support contract Chef had in place with ICE. Late last week, Christ said Chef would continue to support ICE; however, bowing to what he described as internal employee pressure, he reversed that decision earlier this week.

    It’s not clear what impact this move will have on ICE. After all, there are many service providers that ICE could turn to for support. The decision, however, may open a Pandora’s Box, given all the stances IT professionals might take across the political spectrum, said Judith Hurwitz, principal analyst for the IT consulting firm Hurwitz & Associates.

    Whether it’s gun control or conflicts in the Middle East, the potential for IT chaos is high if organizations have to consider a range of potential blowback if they have to consider how employees and potential customers might react, Hurwitz noted.

    In many cases, software companies make their software available online, which makes it exceedingly difficult for them to know who is using it when it was paid for using a credit card, she said. In other cases, no one can prevent anyone from downloading software that has been made available via an open source repository.

    “I’m not sure you can sell software based on who is going to use it,” Hurwitz said. “It’s going to get complicated.”

    The controversy surrounding ICE is likely to escalate further. Last August, protesters disrupted an Amazon Web Services (AWS) to vocally express their displeasure with the company’s decision to provide cloud services to ICE. Last year, Salesforce had to contend with an internal employee revolt over a contract the company has signed with U.S. Customs and Border Control Protection. Salesforce wound up donating $1 million to help families affected by U.S. immigration policies. Chef CEO Christ, in his memo, appears to be following a similar course in involving an ICE contract valued at $95,000 that has been in place since 2015.

    It’s not clear to what degree political passions will influence future IT contracts, but it is clear that organizations need to proceed with care. There are likely to be just as many individuals within an organization on one side of an issue as another. Most organizations these days can’t afford to lose key members of the IT staff over moral and political arguments. The trouble is, fewer IT people seem inclined to agree or disagree in the name of maintaining corporate neutrality.

    — Mike Vizard

  • Never Mind the Bollocks, Here’s the DevOps

    Never Mind the Bollocks, Here’s the DevOps

    What is DevOps?

    “DevOps is a cultural and professional movement” –Adam Jacob

    [movement (n): a group of people working together to advance their ideas.]

    So, who are these people and what’s the big idea?

    The people are system administrators, developers, product managers, QA technicians, security analysts, network engineers, and anyone else involved in the business of developing software.

    The big idea is to increase the value your product or service delivers, more quickly with less effort.

    (Having a product or service that is designed and built well isn’t inherently valuable. The value comes when your customer is able to use your product or service to solve a problem. DevOps is all about delivering value quickly and effortlessly.)

    DevOps practices and technologies are evolving, but here are some of the core concepts paraphrased–be sure to read the links in the footnotes for the full explanations:

    The Three Ways

    • Systems Thinking
      • Learning how everything is interconnected, from concept to customer
    • Amplifying Feedback Loops
      • Cutting the time between action and reaction, failure and success
    • Culture of Continuous Experimentation and Learning
      • Recognizing failure is important data about how and where to improve

    CAMS

    • Culture
      • It’s about how people relate and work, not something you can buy
    • Automation
      • Faster, less error-prone processes help amplify feedback loops
    • Measurement
      • You can’t get where you want to be until you know where you are
    • Sharing
      • Effective teamwork ignores organizational boundaries

    ICE

    • Inclusivity
      • Everyone is responsible for (and benefits from) these practices
    • Complex Systems
      • Because simple systems are simple
    • Empathy
      • Real collaboration requires real understanding of another’s point of view

    That’s the theory from a very high level; the following Q&A provides some broad explanations of related concepts. These are actual questions I was asked in a recent discussion of DevOps.

    Q: What specific skills or experience do I need before I can put “DevOps” on my resume?

    A: It depends. At this point in time when recruiters and/or hiring managers list DevOps in a job posting they are almost always looking for a “DevOps Engineer” (i.e. a sysadmin who knows just enough coding to be dangerous), or a “full-stack developer” (i.e. a developer who knows just enough about system management to be dangerous). The reality is that (as of today) there is no DevOps certification, organization or even manifesto, so anyone who pretends to authority on what is and isn’t DevOps is overstating their case at best, a charlatan at worst.  

    Q: What is source control?

    A: Source control is a repository for files that make up a modern software application during development. It maintains a historical record of changes so it’s easy to review (or rollback to) changes made to an application’s source files. The most popular source control technology today is Git, and GitHub is one of many online services used to manage Git repositories.

    Q: What is Jenkins?

    A: Jenkins is to task engines or “build servers” what Kleenex™ is to facial tissue. It’s currently the most widely used software product for automating various functions of software build and deployment. For example, a system might be configured such that any code change pushed to source control triggers a job in Jenkins to build, test and deploy that code.

    Q: What is configuration management (e.g. Salt, Ansible, Puppet, Chef)?

    A: Configuration management is a means of scripting server configurations so it’s easier to track, deploy or make configuration changes to large groups of systems.

    Q: What are containers?

    A: In the same way that server virtualization allows you to have many isolated “virtual machines” on a single physical machine, container technology allows you to have many isolated application environments on a single operating system. Containers have been around in Unix/Linux for a long time, they just boomed in popularity when Docker came along and made them easy to use. The next version of Microsoft Windows Server (2016) will introduce Windows containers.

    Q: What are microservices?

    A: Microservices are small, independent components of a software application that are built, tested and operated in isolation from the core product. Using microservices enables development to be faster and more nimble than possible when working with a large, monolithic application.

    Q: What is Continuous Integration/Delivery/Deployment?

    A: Continuous Integration is the practice of continuously integrating (and testing) new code with your existing source code. Continuous Delivery is the practice of automating as much of the build/test/release process as possible while still requiring a manual push to production. Continuous Deployment is the practice of fully automating build/test/release all the way into production.

    Q: Are there any conferences or meetups I can attend to learn more?

    A: Yes! The original DevOps conference is DevOpsDays and there are many of these events around the world annually. A popular conference with large enterprises is the DevOps Enterpise Summit.  Various DevOps-related meetups (#CoffeeOps on Twitter) are springing up around the country. Check the CoffeeOps.org website for details, or search for DevOps at Meetup.com.

    Q: [Do I need to understand everything above | Is this all I need] to be or do DevOps?

    A: Absolutely not, on both counts. You can successfully implement a DevOps way of thinking/working by incorporating all or just some of the above, and there are many other tools and practices around delivering value more efficiently. Naturally there are extensive resources available (a few linked in the footnotes) to do a much deeper dive on all these subjects.  

  • DevOps Spring Tour 2015: Keeping Cool with ICE

    DevOps Spring Tour 2015: Keeping Cool with ICE

    One thing I love about conferences is finding out what other people are doing in industry and getting exposure to new ideas. I like to get external feedback on my work because I find it to be helpful. Here’s some highlights from where I’ve been and what I’ve heard so far in 2015, including Alterconf, RSA, A Data Presentation Course with Edward Tufte, and DevOpsDays NYC.

    AlterConf

    My first stop was Alterconf in Atlanta this year. I try to support local events and knew I would gain a lot of perspective from the presenters that I probably wouldn’t find elsewhere. There was a lot of discussion about age bias and discrimination for both younger and older people as we all move through those stages during our lives. Starting a culture of continuous learning early in life was a consistently supported goal among the presenters and attendees.

    My other take away from alterconf is people may or may not be comfortable representing or discussing the different groups they belong to with anyone. Introverts can have a very difficult time talking tech at an event, for instance.  Several speakers at the conference made note of the fact that we will occasionally step on each other’s toes due to what are ultimately misunderstandings and we should be quick to apologize, provide space, and try not to get too upset when someone makes a mistake or appears uncomfortable. I was encouraged to see the consensus lean towards discretely and respectfully bringing any issues up if necessary instead of public exposing someone. Even snapping at a manager in a meeting over a wisecrack about a father ‘babysitting’ his own kids does more harm than good. You shouldn’t stomp on anyone with both feet over failed build either. Having a calmer conversation with a smaller audience if possible was the advice I heard repeatedly throughout the day.

    We’ve been having more conversations around anxiety and burn out as a community and talking a lot about comfort, learning, and danger zones. I’m going to openly admit I was more nervous than usual going into alterconf as a white cisgendered heterosexual male. It may have had something to do with the fact that I didn’t know what cisgendered meant before the event. The anxiety quickly passed after I found my seat and realized there were plenty of people there just like me. At a minimum all of us were passionate about technology. It was a very open and welcoming space and I gained a lot of perspective that I wouldn’t have otherwise. There are 5 more sessions scheduled this year if you may be interested in gaining some perspective from a broader range of people that are also passionate about tech.

    DevOps Connect @ RSA

    DevOps Connect @ RSA was a uniquely awesome experience. I met a lot of security folks coming into the DevOps space for the very first time which was encouraging to see. I also got an up close look at the security industry and why they need to gain some insight from a DevOps perspective. The expo floor was the most commercialized one I’ve ever seen at an event. It reminded me of a midway at a state fair. I wouldn’t have been shocked if someone had called me in for a go at the ring toss. Most of the sales pitches sounded like magic beans to me, bolted on for instant risk mitigation.

    The one vendor that separated themselves as an exception to this was Tufin. Tufin’s security orchestration suite is a comprehensive solution for network security management providing visibility, change tracking, analysis and auditing for firewall policies, network devices and cloud platforms. It also provides automatic firewall change management and application connectivity management. It assures a tight security posture, rapid service delivery and regulatory compliance across all enterprise platforms.

    I haven’t taken it for a spin myself, but Tufin definitely impressed me with their demo and orchestrated approach to the problems security is currently facing.

    Certification was also a consistent topic of conversations at RSA. I think there’s a lot of misunderstanding in this space between arbitrary compliance and compliance that legitimately mitigates risk or provides a return on invested time and energy. This sentiment echoed through Secretary Jeh Johnson’s keynote, as he announced the opening of a satellite cyber security office in Silicon Valley and an invitation to cooperate with concerns surrounding encryption.

    Data Visualizaiton Workshop with Dr. Tufte

    My next stop was Boston for a data visualization workshop with Dr. Edward Tufte. When I told him I was a devOps engineer working on dashboards in an enterprise environment I could tell he was curious but may have not heard the word devOps before. The person I was speaking with before Dr. Tufte came by mentioned a health care system that still faxed data between offices and the problems it caused with younger employees that had never used a fax machine before. It was obvious to Dr. Tufte that they should switch it to a web based system, and the frustration with compliance and risk concerns that prevent that change from happening were not lost on him. For lack of better words and opportunity, I offered this as the type of problem devOps is currently trying to solve. The perspective I gained from the session that followed was from an experienced professional that can fully appreciate the current state of the art. I believe I appreciate it now more than ever, for which I’m thankful.

    DevOpsDays NYC

    The topic of discussion was ICE, or Inclusion, Complexity, and Empathy, based on a post by Dave Zwieback from earlier this year. The talks focused on how to try to cooperate better between teams both at home and abroad and suggestions on how to handle departments that are more territorial in addition to dealing with our own stress levels.

    Attendees seemed particularly grateful towards John Willis and Justin Lintz for talking about burn out and anxiety in our industry among heavier topics. If you’re inclined to start a conversation about these types of health issues in your community then you probably should. I try to shut up and listen as much as possible, and that’s often helps more than one would think. If you have a venue to show John’s video before an open spaces event all you have to do is book the room and be available. Creating an opportunity to discuss these issues is a huge step forward in my opinion.

    But wait! There’s More! I’m giving an Automating Enterprise Security Talk at Gluecon outside of Denver later this month. I spoke about this at devOps Connect @ RSA but I always update my content between talks as I get more feedback from folks. If you happen to be at Gluecon this year we should have a conversation over coffee, a beer, or a meal. From my experience a chat tends to be more fun in person than online, as I for one get tired of staring at screens all day.