Category: Features

  • The Impact of Automation: Considering 3 Facts

    The Impact of Automation: Considering 3 Facts

    I’ve been interested in the ramification of automation on human employment for a while now. My profession, IT, is bringing more automation to the planet every day. I would be irresponsible to not understand the ramifications of my work.

    Recently in my research I came across three facts that gave me pause. The facts are:

    1. Due to improvements in automation, it takes fewer people to create more goods and services.
    2. We are producing more good and services than we ever have, possibly more than we might ever need.
    3. Just as it takes fewer people to create goods and services, fewer people are garnering more of the wealth being created.

    The implications of these facts are dramatic and the implications are far-reaching. Allow me to elaborate.

    Fewer People Create More Output

    Consider this fact: In 1790 90 percent of the people in the United States were engaged in agriculture. Most of the people fed the population. Two hundred years later, 2.9 percent of the population was engaged in agriculture. A relatively small amount of people create enough food for all.

    Also, consider this one: In 1980 it took 26 people to create a $1 million in output. Today it takes 2.6.

    The pattern is obvious. As time marches on, it takes a lot fewer people to create a lot more wealth. Why? Automation technology. Every year we create more hardware and software that does work previously done by humans. Automation never tires and produces as much as we want, when we want. The trend is strong and consistent. The rate of innovation is increasing. And as the rate increases, more people will be displaced by machines and software. I talked about this extensively in the first article I wrote in this series.

    Let’s move on.

    We’re Producing All We Want — and Then Some

    Today China, India, Brazil, Vietnam, Indonesia, Pakistan, Thailand, Mexico, Italy and Turkey combined produce 18.5 billion pair of shoes year.  That’s more shoes made a year then there are people on the planet. (The current population worldwide is 7.5 billion.)

    Today there are 260 million cars registered in the United States,  which comes out to a little more than one car for every adult in the population.

    The number of cellphones in China in 2014 is 1.14 billion, in India there are 1 billion and in the United States there are 327 million. Just about everybody in these countries has a cellphone. And the prices keep dropping. Eventually, everybody on the planet will have a cellphone—which, by the way, has more computing power than did the computers onboard an Apollo spacecraft.

    Productivity no longer is constrained by the capacity of human labor to create goods. Whereas before the Industrial Revolution not enough goods were produced to satisfy consumer demand, today things are reversed. The modern struggle is finding enough buyers to purchase what’s been made.

    As I mentioned earlier, we’re really good at making as much as stuff as we want, whenever we want. And yet, despite this abundance, there is a problem.

    Wealth is Concentrated to a Few

    A report that came out earlier this year reveals a troubling fact: Eight people on Planet Earth own as much wealth as 50 percent of the rest of the global population. True, there is some dispute going on about the methods by which this number was determined. But, even if the number is 30 percent, the disparity in the distribution of wealth is astounding. More wealth is being concentrated to fewer people even as automation becomes more prevalent. Abject poverty may not be rising, but increased displacement of workers is. As workers become displaced, their wealth diminishes.

    Saying “Things must change” is absurd. Things will change. The question is, “What will that change look like?” Will we have a fully automated society in which there are more than enough shoes to go around, or will we still have a world in which there are those that go shoeless?

    What Do We Do Now?

    In previous articles I’ve talked about Universal Basic Income (UBI) as a possible way to address the problem of providing income for displaced workers. UBI is a viable solution, but not one that will to come to fruition in the near future. The problem is here today. So, what do we do?

    Read on.

    Economic Sustainability Over Economic Growth

    I’ve mentioned many times, there is a good argument to be made that the jobs taken away by automation are not coming back, nor will there be an abundance of new jobs to replace those taken. My prior article supports my assertion. Eighty-eight percent of job displacement is due to automation. The need for human labor is diminishing at accelerated rates. That’s the bad news. The good news is that automation has allowed us to grow our productivity more than we’ve imagined possible. But growth is not the answer. On a planet full of shoes, there are still those who go shoeless. The change we need to make is to move from an economy based on growth to one based on sustainability.

    Changing the Way We Talk About Things

    I’ve come to accept that we cannot grow our way into economic prosperity any more than we can grow our way into good health. In fact, too much growth can kill you—just ask someone who suffers from morbid obesity. So I made the change in how I talk about prosperity. I no longer use the term “economic growth.” Rather, I use the term “economic sustainability.” I am a big believer that thinking follows language. Change the way we talk about something and we’ll change the way we think about that thing. If we want to have a sustainable economy, we need to start talking that way.

    Creating Wealth for All

    Okay, I’ll come clean. I think that given the current trends, too few have too much. More wealth parity is required. But, as we have learned on the terrain, overt wealth redistribution is not the answer. We cannot tell somebody we’re going to take away a part of their wealth without upsetting them. But, we can set an example in the benefit of sharing the wealth to benefit all. We in IT have been doing it for years—it’s called open source. We learned a few years back that when we give it away, we get it back. The trick now is to go beyond IT and make the open-source mindset part of our civic sensibility.

    At some point in the not-too-distant future—say, about 20 years—we will be at almost total automation. If trends continue, there will be few with a lot and a lot with a little. People that don’t have a lot don’t have much to lose. Wealth inequality creates turmoil, unrest and overt aggression. If you think not, take a look at the excesses of France under Louis XIV which, by the time you got to Louis XVI, led to the French Revolution and the Reign of Terror. Or consider that the wealth disparity during the last generation of the house of Romanov led to the Russian Revolution. Nicholas dined in lavish halls while the serfs starved. Lenin prevailed.

    Wealth parity creates political stability and political stability creates prosperity for all. Achieving wealth parity comes about by sharing. Again, we who have code on GitHub know this. Again, the trick is to make the open-source dynamic part of our civic sensibility.

    Let me close by providing one more fact. One of the thing I’ve learned in my research is that as the population rises in a country, so does the GDP.

    Figure 1: Population growth among 9 most populous countries, 1960 -2015 (Source World Bank)

    Figure 2:  GDP Growth, 1960 -2014 (Source World Bank)

    But, again the trend is that the wealth goes upward to a few. So we have a choice. As automation increases, we can learn to share the wealth and create a world that is stable, sustainable and prosperous. Or we can keep the current trend in place, allowing the few to have the most. And because we don’t need a lot of human labor to maintain the levels of production possible, rather than risk ongoing political upheaval and civil unrest, we can just get rid of those that unfortunately are on the wrong end of the distribution curve. Their labor is no longer needed.

    Is such an idea vile and extreme? Yes, it is. Is it one without precedent? I’ll let you be the judge.

    — Bob Reselman

  • The 2016 DevOps Dozen Winners Announced

    The 2016 DevOps Dozen Winners Announced

    In what turned out to be a much bigger job than we anticipated, we have gone through the numbers and checked them twice (actually more like 20 times). All of us here at devopsy.kinsta.cloud are happy and proud to announce the winners of the 2016 DevOps Dozen!

    With thousands of votes cast in just the finals alone, it was a daunting task to verify votes and select the winners in each of the 12 categories for awards this year. Also several of the categories had incredibly close races with just a few votes separating the winners from the other finalists. But there can be only one, winner in each category that is.

    So without further adieu, here are the winners of the 2016 DevOps Dozen awards:

    Best DevOps Open Source Project: Jenkins

    The DevOps world is chock full of great open source projects. Many of them have huge communities who are  very passionate and involved. The Jenkins community holds its own with any of them. More importantly, Jenkins seems to be at the center of the DevOps/CD  world.

    Also congrats are in order for CloudBees who while not managing the Jenkins project do a great job of shepherding and nurturing it.

     

    Best DevOps Commercial Solution: Automic

    Another extremely competitive category with so many great finalists. Automic was the choice of the voters here and I guess to CA Technologies as well, who just closed on the acquisition of Automic last week.

    We can’t move on without acknowledging and congratulating the other finalists in this category as well as the bevy of DevOps tools and tool vendors in the market though.

    Best DevOps Company Executive: Barry Crist, CEO, Chef

    Well deserved recognition for one of the leaders of our industry. I still remember when Barry was first announced as the CEO of Chef, as they embarked on a major rebranding effort, shedding OpsCode and firmly moving to an enterprise solution path.

    Along with CTO Adam Jacob, Chef continues to lead with innovation in both product and go to market. In many ways Chef represents the best of the DevOps community and Barry has a lot to do with that.

    Most Innovative DevOps Solution Provider: Ranger4

    OK I have to admit it, I was pulling for Ranger4 in this category. Helen Beal and Steve Green are great people who were out there evangelizing and leading in DevOps consulting way before the current Cambrian explosion of DevOps consultants we see today. Their DevOps Liftoff Workshop and their latest, DevOps for CEOs, are both high water marks in the industry. Congrats to the entire Ranger4 team.

    Make no mistake though that DevOps consulting is a rapidly growing market with many different solution providers out there. Ranger4 on top of their a first mover advantage continues to blaze a path that others follow.

    Most Innovative DevOps Solution: IBM Bluemix Garage Method

    There is no shortage of innovation in the DevOps space, but what IBM has done with the Bluemix Garage Method is really ingenious. It is not software or hardware, it is not SaaS, it is truly a methodology.

    The method takes IBM’s lessons learned during their own DevOps transformation, combined with tools and processes, to form a complete blueprint that allows organizations to “innovate like a startup, while scaling to the enterprise.”

    Top DevOps Evangelist: Jason Hand, VictorOps

    Again a very close margin of victory here, but a well deserved accolade for evangelist/author Jason Hand of VictorOps.  Luckily, for VictorOps they don’t pay Jason by the mile as it seems he is constantly on the road. I don’t remember the DevOps Days or other DevOps event where I didn’t see Jason there. Somehow in between all of this travel, Jason also found time to write a book, ChatOps.

    We are blessed in the DevOps field to have many worthy recipients for this award, but kudos for Jason for being the people’s choice here.

    Successful DevOps Transformation: Nationwide

    Many of our stories here on devopsy.kinsta.cloud, as well as just about every presentation at Gene Kim’s DevOps Enterprise Summits are about successful DevOps transformations. Name the vertical and there is probably a DevOps transformation story you have heard from one or more organizations in that vertical.

    Nationwide is a DevOps transformation story that we here at devopsy.kinsta.cloud are very familiar with. Primarily through the efforts of Carmen DeArdo who is one of the leaders of that transformation. We have interviewed Carmen a number of times and for me the way Nationwide has rolled out DevOps in a deliberate manner across the organization and still does so today is truly a model to be emulated. Congrats to the Nationwide DevOps team. When it comes to DevOps, “Nationwide is on your side (sorry couldn’t resist).”

    Best New DevOps Solution Company: DBMaestro

    Winning the “rookie of the year” in an industry that is itself still immature is no easy task. There seems to be a new DevOps company coming out of the woodwork everyday. But DBMaestro has managed to stand out from the crowd. Pioneering in the “DevOps for the database” market, DBMaestro has gained attention not just with a great product/service, but also by producing high quality content to help evangelize and educate the DBA market about DevOps.

    Of course the thing about winning best new company is now the pressure is on. We expect big things from DBMaestro going forward. Can’t wait to see what they do for an encore.

    DevOps Transformation Executive of the Year: Angel Diaz, IBM

    Dr. Angel Diaz is a charismatic, dynamic leader at IBM. He is VP of Cloud Architecture and Technology. In that role Angel’s team pioneered IBM’s BlueMix platform. Hearing the story how Bluemix came to be is a great story of innovation and entrepreneurial inspiration.

    Angel and his colleagues were able to move “Big Blue” and teach the elephant to dance by adopting Bluemix. Not just the Bluemix platform, but also such innovations as the Bluemix Garage and the Bluemix Garage Method. Dr. Diaz is not afraid to take chances and innovate to keep IBM at the forefront of technology. This award is well deserved for leading a massive DevOps transformation that has not only made IBM a leader in offering DevOps solutions to market, but also having IBM eat its own DevOps dogfood.

    Best DevOps Presentation of the Year: Better, Faster, and Cheaper. How? by Damon Edwards & John Willis

    Again, how blessed are we in the DevOps space to have such a wealth of great presentations to pick from? Whether they be slides from webinars or video from the many, many conferences around the world, there are some really great presentations that inform and educate us all.

    One presentation stood out among them this year. It happens to be one that I was lucky enough to catch while in London for the 2016 DevOps Enterprise Summit. Damon Edwards and John Willis (who literally had just stepped off a redeye from the US and rushed over from the airport) delivered what I have come to call “2 out of 3 ain’t bad, but why settle”. To me it is the best way to show what the advantages of DevOps. Why you can have both better, faster and cheaper (and might I add more secure).

    Of course Damon and John have been delivering killer DevOps presentations for years now and this is just the latest in the line. Both John and Damon are very deserving of this award and congratulations to them.

    Best DevOps Book/eBook of the Year: The DevOps Handbook, Gene Kim, John Willis, Jez Humble and Patrick Debois

    While there are several great DevOps books that came out last year, one really was in a league of its own. The highly and long anticipated companion/sequel to the Phoenix Project, The DevOps Handbook has lived up to the expectations of the industry. Gene Kim assembled a DevOps superband of rockstars to help him as co-authors and they delivered a great book.

    The DevOps Handbook is a collection of over 40 case studies broken into several categories. It claims to show, “How To Create World-Class Agility, Reliability, & Security in Technology Organizations” and it succeeds on every level. The DevOps Handbook will be a required component of DevOps collections for years to come.

     

    Best devopsy.kinsta.cloud Article of the Year:  5 Things DevOps is NOT by Shelbee Smith-Eigenbrode

    While not the story with the most views, 5 Things DevOps is NOT struck a chord with our readers. It was one of the most widely commented articles of the hundreds of articles we published in 2016. Additionally, it has a long tail in social media with comments on Linked In, Facebook and Twitter as well.

    Shelbee Smith-Eigenbrode hasn’t written a lot of articles for us here at devopsy.kinsta.cloud (hint, hint), but she brings a real life view of DevOps in the field that she has learned in her role at IBM. It is this hands on view that I think allowed her to capture the sentiments in this article that so many identified with.

    Congrats to Shelbee and hope this encourages her and you to consider contributing your own thoughts on DevOps to us here on devopsy.kinsta.cloud. We are always looking for quality content. You can write us at editor@devops.com with your thoughts on contributing your own article of the year.

    Well there you have it. A dozen winners in the 2016 DevOps Dozen awards. Congrats to all of our winners and also congrats to all of our finalists. This was such a strong class of finalists.

    The trophies are already on their way to the winners and we hope to see pics of them on the desks of the winners soon!

    The DevOps Dozen for 2017 nominations will start in August so stay tuned for details if you are interested in throwing your hat in the ring for next year.

    — Alan Shimel

  • AppDynamics Buy Expands Cisco’s DevOps Agenda

    AppDynamics Buy Expands Cisco’s DevOps Agenda

    AppDynamics’ $3.7 billion acquisition by Cisco Systems has two major implications for the DevOps space. On a tactical level, Cisco has committed to distributing AppDynamics’ agent software everywhere from the public cloud to individual devices connected to the Internet of Things (IoT) and in between. On a more strategic level, the company is positioning itself to be able to uniquely correlate IT operations data generated by applications and IT infrastructure to give organizations comprehensive visibility into their entire DevOps environments.

    During a briefing with analysts and the media this week, Rowan Trollope, senior vice president and general manager of Cisco’s IoT and Applications Business Group, described how his company sees AppDynamics as a linchpin acquisition that propels the company well beyond its well-established networking and server infrastructure base. After the merger is completed, expected sometime in the third quarter, AppDynamics will continue to operate as an independent business unit within the IoT and Applications group, and current AppDynamics CEO David Wadhani will report to Trollope.

    Trollope described AppDynamics as a complement to Cisco’s ongoing efforts to drive more recurring revenue. The company, which offers an application monitoring service delivered via the cloud, was poised to shortly go public prior to being scooped up by Cisco. AppDynamics is employed mainly by IT organizations to monitor applications running on public clouds. But Wadhani noted one of the fastest-growing segments of AppDynamics’ business is monitoring applications running in private clouds.

    The data AppDynamics gathers in those environments can be correlated against, for example, the data Cisco collects via its Tetration analytics application, which the company launched last year. That capability, Trollope said, will significantly increase the total Cisco value proposition.

    In fact, as hybrid cloud computing scenarios based on microservices and containers become more common, Wadhani noted that monitoring of complex applications running in production across multiple clouds will become a more crucial requirement. AppDynamics recently extended its monitoring service to include support for containers deployed in these environments.

    Under the leadership of CEO Chuck Robbins, extending Cisco’s reach across the enterprise has become a high priority. Cisco recently abandoned a cloud interoperability service strategy. But its acquisition of AppDynamics suggests the company is shifting its focus to higher-margin software that generates recurring revenues across multi-year contracts.

    Following the acquisition, Trollope said Cisco also plans to take advantage of its existing relationships with senior business and IT leaders to advance a vision of DevOps that provides organizations with visibility all the way down to how each customer engages with their IT resources. The issue Cisco needs to navigate is the degree to which those senior executives actually exercise control over DevOps. To date, DevOps has been more of initiative led by developers and IT operations staff than mandates from senior executives.

    Wadhani said Cisco’s direct and indirect sales staff should significantly expand the number of organizations that are exposed to AppDynamics services. That means one way or another, DevOps is about to become a much broader discussion across the enterprise.

    — Mike Vizard

  • 5 Ways DevOps Can Help Improve IT Security

    5 Ways DevOps Can Help Improve IT Security

    You already know DevOps can make software delivery faster and more efficient. But did you know it can help to keep software more secure, too? Here’s how.

    DevOps refers to a set of practices and cultural priorities related to the way software is designed, produced and deployed. It emphasizes collaboration between developers (the people who write code), IT Ops (the folks who manage software in production) and everyone in between—such as software testers and designers.

    When done properly, DevOps greatly reduces the time it takes to bring software from idea to implementation to end user delivery. It also adds efficiency to the software delivery process in many ways. It allows different team members to work in parallel, for example. It also ensures that coding problems are found early in the delivery pipeline, when fixing them requires much less time and effort than it does once a bug has been pushed into production.

    DevOps and Security

    But making software delivery faster and less costly isn’t the only thing DevOps does. DevOps also helps make software more secure.

    It does this in several ways. Consider the following:

    • Visibility. DevOps encourages constant communication between all members of the IT organization. That maximizes each team member’s visibility into the software being developed. In so doing, it places as many eyeballs as possible on the code, at all stages of delivery—which maximizes opportunities for your staff to find security flaws before code is released into production.
    • Automation. In the DevOps world, software delivery tasks are automated as much as possible. With automation comes consistency and predictability—and a much lower chance that human error during a manual process could introduce a security vulnerability.
    • Fast updates. DevOps enables a much faster pace of software delivery. That means that security bugs (and bugs of all kinds, for that matter) can be squashed very quickly by rolling out a fix.
    • Tool-agnosticism. With DevOps, you can use whichever tools or programming frameworks you like. You’re not bound to particular platforms or vendors. That’s important from a security perspective because it empowers you to adopt the tools that are most secure for your needs—not the ones you’re locked into because you have an outdated, inflexible software release process.
    • Agile technology. While DevOps doesn’t require you to use any specific type of tool, DevOps teams tend to favor next-generation architectures and technologies, like microservices and containers. These help to make apps more secure by reducing attack surfaces and enabling quicker reaction. If you deploy your app using containerized microservices, it becomes harder for attackers to compromise your entire app, because an attack against one microservice doesn’t give them control of the other ones.

    DevOps isn’t a silver bullet when it comes to cybersecurity, of course. Keeping your systems and data secure requires careful planning on a number of fronts and implementing a variety of tools.

    But DevOps—especially a highly automated, DevOps-based release process—should be one important weapon in your cybersecurity arsenal.

    — Chris Tozzi

  • F5 Networks’s State of Application Delivery, 2017

    F5 Networks’s State of Application Delivery, 2017

    For the last three years, F5 Networks has surveyed its users and presented the “State of Application Delivery” report. This year’s report is already a couple of weeks old, and I’ve had the opportunity to read through it. There is good information in there for “NetOps” people—those who are focused on the network but want DevOps-style management. The report discusses the trends and what its customers—which lean to the larger, more established organizations—are doing.

    DISCLOSURE: I’m a former F5 employee, and overall, I loved the company. Its upper management has managed to navigate bad times and thrive in good times, and the direction of the company was generally excellent while I was there. My reasons for leaving had nothing to do with top-level management or product. In short, I’m a fan of F5. Also, my wife is still an employee of the company and—worse than that—had a hand in creating both the survey and the resulting document. And Lori sometimes also writes for devopsy.kinsta.cloud. Thus, any criticisms I offer here I will have to be willing to defend on social media, at editorial meetings and at the dinner table.

    With all that said, since readers can download the report and form their own opinions, I’m comfortable writing about this report. And I’ll even risk doing battle over the steak fries for my loyal readers.

    F5 asked nearly 2,200 users of its gear from a variety of industries a series of questions regarding how they use application services—those things such as load balancing, web application firewalls or DDoS protection that exist for an application but aren’t part of it. Included also were DevOps questions and automation questions outside the realm of DevOps.

    While much of the report is of general interest for any IT practitioner, some of it is specifically of interest to DevOps practitioners. So, with the exception of a few sweeping statements, I’ll restrict myself to the DevOps-relevant portions of the report.

    Insider side note: Lori has mentioned F5 has a metric ton of data it was unable to squeeze into this report, and she would be talking about off-and-on for a while at her F5 blog. If this topic interests you, it might be worthwhile to follow her.

    The first thing to visit is the overall list of takeaways. The report offers four “Key Findings” and, interestingly enough, three of them are relevant to DevOps. When you dig into the fourth (security-related) key finding, you discover that it, too, is at least tangentially related to DevOps.

    While I don’t want to give away the entire report, I will mention the three items directly related to DevOps:

    1. Digital Economy drives application services adoption.
    2. Cloud is growing and skills are needed.
    3. Cost savings are the primary driver for DevOps in their survey base.

    An increase in application services that can be automated kind of strongly implies DevOps, while cloud and DevOps go hand in hand, and the last point explicitly is DevOps.

    The report is packed with information about what F5’s customers are doing, what’s important to them moving into 2017 and what they plan to implement soon. Overall, it is a great read, and might bolster your appeals for executive backing or increased funding.

    There are some oddities in the report, though. I’m not a fan of the editing; some sentences seem clunky (using the same word twice in a sentence with different assumed context, for example); and one list of percentages is for some reason organized least to greatest, while all others are organized greatest to least.

    While editing errors are distracting, the biggest issue I had with the report was the inclusion of Python as a “framework” (along with VMware, OpenStack, Puppet, Chef …). The assumption is made in the accompanying text that this indicates the level of homegrown automation, but since there are many ways to implement homegrown automation, this is at best a low point indicator of that. Overall, it feels out of place in the list:

    DevOpsTools
    DevOps tools as surveyed by F5 Networks.

    But honestly, there is enough other information about trends and number of these “frameworks” in use per org packed into this section that I’m willing to view inclusion of a language as a simple oversight that can be explained away because lots of organizations are using python for automation (I have, at more than one organization).

    The report also talks about the average application having double digits of application services deployed for it. This seems high to me, but it is data from a survey of F5’s customers, and if you’ve already paid for this bundle of services, perhaps you are more likely to make use of as many as possible. What this points to, for me, is an automation of the overall application environment. Considering the commentary F5 received in response to skills questions, it makes sense that automating solutions that can easily be automated would be an easy choice for their respondents.

    Note that in the graphic above, the company did not restrict users to “What frameworks are you using for network configuration?” It might be a reasonable assumption to think it did, as F5 is primarily a networking company (don’t tell the execs I said that—they seem to be repositioning as an application services company these days), but I asked, and the company put no limits on responses. That shows uptake of Puppet among its customers to be far smaller than I would have expected, personally, considering the core of its customer base should be Puppet’s sweet spot—traditional enterprises in a variety of industries.

    The weighting of respondents across roles might have some play in how these are ranked, though. There is a preponderance of networking and management types in the response list, with fewer security, dev, architecture and DevOps types. This could skew results, even if the organization list is relatively balanced across industries.

    Overall, take a look. It’s solid information, with some interpretation available and more commentary on verticals and use cases. It’s definitely a document worth having on hand when explaining the value of what you’re doing, or attempting to expand what you’re doing.

    — Don Macvittie

  • 2017 Security Blogger Awards – Open for Voting!

    2017 Security Blogger Awards – Open for Voting!

    It’s another year, and another awards ceremony to come at the Security Blogger Meet-Up at RSA Conference in San Francisco. It’s time to vote for your favorite blogs, which were selected solely by our esteemed influencers: Ericka Chickowski, George Hulme, Kelly Jackson-Higgins (Dark Reading) and Don MacVittie. We are very grateful for their taking the time to support our bloggers and the event. 

    Before you vote (https://www.surveymonkey.com/r/sbn2017), remember a few things from last year:

    • Anyone can vote in the awards. However, a valid email is required and it will be verified. Only one vote per IP
    • Any nominee caught trying to “game the system” will be disqualified. Please try to play by the rules and may the best blog win
    • If you are going to RSA be sure to register for the Rugged DevOps event on Monday at the Moscone Center. Free to anyone with any type of RSA ticket (even just expo pass holders). You can register for the event on the RSA Conference website. Here is a code for a free expo pass, 1U7DEVOPSXP. If you are already registered for RSA, you can reserve a seat here.
    • You can also participate in our “Security @ the Speed of DevOps” survey here.

    Here are our nominees for the 2017 Security Blogger Awards

    Most Entertaining Security Blog

    Most Educational Security Blog

    Best New Security Blog or Podcast

    Best Security Podcast

    Best Blog Post of the Year

    Best Corporate Security Blog

    Please vote today!

    — Alan Shimel

  • VMs, Containers, Cloud, Cluster: Scheduling Differences

    VMs, Containers, Cloud, Cluster: Scheduling Differences

    Scheduling is a large part of making the data center go, and more to the point of making the virtualized (be it VMs, cloud, containers, or clustering) portion of the data center work.

    While there are a lot of variables to virtualization performance, scheduling impacts performance all of the time. And yet we only really talk a lot about it in clustering (where a robust scheduler on par with an OS scheduler is required).

    There’s a reason for that, and it is worth exploring.

    (Side note: I was talking about this blog with Lori while I was writing it, and she reminded me of when we took our Masters’ courses, the Operating Systems class used Homer Simpsons greedily wanting donuts as our scheduling project. So whenever we think scheduling, we mentally hear one of the many Homer processes being denied a donut and going “D’oh!”)

    For virtual machines, scheduling is largely forgone in favor of other resource utilization. Virtualization only cares about CPUs and memory requirements when the virtual machine is created. You tell it then, and the only time you worry about it again is if you demand more CPU cores than the physical hardware can provide—and in some cases, CPU virtualization will allow you to keep spinning up VMs even after that. Only the real scheduling mechanisms actually can be at odds with each other in a heavy load situation. The host OS scheduler, for example, could swap out your VM’s active thread at the same time the guest OS has raised the level of importance for an app to “insanely high, do it now.” Although this only begins to show if basic rules about servers and loads are ignored, it does happen.

    You get the same issues with private clouds. Why? Because even though everyone in the marketing world pretends it isn’t true, private cloud and VMware ESXi essentially are the same underlying toolset. And usage patterns in the enterprise show not only does everyone know that, but also the differences are less substantial than any of the organizations involved want to admit. Not that they are the same code, but in practice, they do the same things.

    The one place where these two (and public cloud for that matter) really make use of scheduling is when automatically responding to spikes in usage that threaten to bury a system. However, solutions to usage spikes are not part and parcel of these systems; they are crafted by DevOps (or Dev, or Ops) folks who work at places where dropped connections are lost money and, thus, a quick response of growing the pool of available servers and then later shrinking it is important. But because they are using their own metrics to determine the need, more of these systems are implemented in application provisioning tools than in cloud or virtualization software. We could argue about where this functionality actually belongs, but not really where it is implemented today.

    I kind of bled into public cloud there, so will address it. When people talk about it being more “agile” or “adaptive,” they mean “with this quasi-scheduling code we wrote to spin up instances at need.” It doesn’t matter if the “code” is a python script or an Ansible playbook—they did the scheduling, not the system.

    That leaves clustering software (such as Mesos). Because clustering software treats many machines as one big thing, it requires a scheduler to manage the resources. In the case of Mesos, the central scheduler really isn’t that smart, and I think that is a genius implementation. It knows what resources (CPU, memory) each machine has available, it knows what resources have been assigned from that machine, and for each of the “frameworks” (think of them as job executors; though that’s a bit simplistic, it’s perfect for this discussion) what it needs to get its work done. Then it does a best match, offers resources to frameworks and waits for more resources to come available from finished executions.

    So in the world of VMs, if you have 50 unique applications that need resources, you create 50 VMs to service them. In either cloud environment, you do the same. It is a joke we like to make that because of microservices, containers are treated like VMs, except if you have 50 unique applications, you create 500 containers, but the reality is that they are exactly like VMs in many use cases, and make 50 containers when containerizing existing apps. Taking a look at MesoSphere’s 2016 survey of clustering users, you can see that a fair number of clustering users are using containers with Mesos and DC/OS, while many of them are not doing it exclusively with microservices.

    Source: MesoSphere user survey, August 2016

    In the clustering world, you have what presents as one big monster machine that is going to run these applications as resources come available, so if your 50 applications require fewer resources than the cluster offers, they simply execute in parallel; if you don’t have enough hardware to run them, unlike with VMs, you can just queue them up and, assuming the cluster isn’t over-burdened, eventually they all will run.

    This gets more interesting when containers are added to clustering (a common environment), because then you do have discrete containers, but the scheduler still manages how many resources are available/in use, and the container architecture allows the app to carry its requirements with it across the cluster.

    Why do we care? Because you know what your workloads are and which scheduling methodology is more important to your organization. If there are 50 applications that all have steady resource needs and run all of the time, then virtualization might be right for you, but if the organization’s workloads are shifting constantly and resources need to be cycled at a high rate, clustering might be right for you. Either way, knowing what’s out there is never a hindrance.

    — Don Macvittie

  • DevOps is More Than Just Automation

    DevOps is More Than Just Automation

    DevOps is a lot of things. What DevOps is, what DevOps does and how an organization adopts and implements DevOps tools and practices are largely subjective, but there are some foundational elements that are fairly ubiquitous. One of which is automation. As pervasive as it is, though, DevOps is not automation and automation is not DevOps.

    The Preface of “The DevOps Handbook” lists a number of prevailing myths about DevOps, including the idea that DevOps is just “infrastructure as code” or automation. The book goes on to explain:

    While many of the DevOps patterns shown in this book require automation, DevOps also requires cultural norms and an architecture that allows for the shared goals to be achieved throughout the IT value stream. This goes far beyond just automation.

    The book also shares an anecdotal quote from technology executive Christopher Little: “DevOps isn’t about automation, just as astronomy isn’t about telescopes.”

    I prefer a golf analogy. If DevOps is the game of golf, then automation is like the putter. The game itself may be played for different reasons by different individuals—exercise, competition, just to get out and enjoy nature—but the fundamentals are the same no matter what the ultimate goal is. There is a wide variety of clubs available and strategies that can be employed to get the ball from tee to green, at which point the putter is somewhat indispensable. It is technically possible to tap the ball in using some other club, but everyone will agree that the putter is the best tool for the job. As necessary as a putter may be, though, the putter is not golf and golf is not the putter.

    The important thing to remember is that automation is simply a tool or method for achieving the goal. It, like any other facet of DevOps, has to be part of a broader cultural shift and mindset.

    It was about a year ago that I theorized that microservices could make the “Ops” in DevOps obsolete. If everything—infrastructure included—can be implemented in code and automated, will we still need people to be involved? The answer then—and now—is yes, because DevOps is about more than just automation. Its evolution is to one of enabler rather than job-killer. As more functions are automated, people can focus on bigger and deeper issues and create new innovations instead of focusing on mundane, repeatable tasks.

    You can’t do astronomy effectively without a telescope, and you can’t play golf effectively without a putter. Similarly, you can’t effectively do DevOps without automation—but it is theoretically possible, because it is just one element of DevOps.

    I can’t imagine why anyone would want to do DevOps without automation, though. It wouldn’t make any sense—like trying to look at the stars without a telescope, or sink a golf ball from 18 feet with an 8-iron. Although DevOps is more than just automation, the most effective and efficient way to succeed at DevOps is to automate everything that can be automated so you can stay focused on the big picture.

    — Tony Bradley

  • DevSecOps @ RSA Conference 2017

    DevSecOps @ RSA Conference 2017

    One again this year, devopsy.kinsta.cloud, Sonatype and RSA Conference are teaming up to bring a Security/DevOps day of learning and networking to RSA Conference 2017 in San Francisco on February 13, 2017.  The event is DevSecOps @ RSA Conference 2017. Building on the previous two years of great events, this yearsevent promises to be even better. Some of the confirmed speakers are below and you can see for yourself what an amazing array of sessions there are. The best part is attending all of the RSA DevSecOps events are free.

    DevSecOps Sessions

    The line up for DevSecOps includes DevOps and DevSecOps pioneers, John Willis, Damon Edwards, Jez Humble, Dr. Nicole Forsgren, J. Paul Reed, Josh Corman, Shannon Lietz and more. Check out the site page for full details on speakers and topics.

    Attending the full day event (10am to 4pm) is free, but you need to register with RSA Conference. If you are already attending RSA, you need to modify your registration to indicate you are attending DevSecOps (or Rugged DevOps). If you are not already registered you can do so and receive a free expo pass to RSA Conference, which will allow you to register and attend the DevSecOps conference. You can use the code: 1U7DEVOPSXP and register here.

    DevOps Wine-ing (No Whining) Party

    In addition to the full day of amazing speakers, we will host the annual DevOps Wine-ing (no whining) cocktail party, immediately following the sessions. You need to be registered separately for the Wine-ing event. There is a link to the eventbrite registration here.

    The wine-ing event is from 4:30 to 6:30 and should once again be a great time for the security and DevOps tribes to intermingle. A tip of the hat to Josh Corman who is speaking at DevSecOps for starting the DevOps Wine-ing party 4 years ago.

    Security @ the Speed of DevOps Lunch ‘n Learn

    On the following day, Tuesday we will host a lunch-n-learn on the “Security at the Speed of DevOps” report we are co-producing with the Cloud Security Alliance. We will have a panel including George and some leading DevSecOps and Cloud Security experts discussing the findings over lunch at Jillians. Again this event is free but you need to register for it here.

    The report is being written by George Hulme and is based on a survey co-produced and distributed by devopsy.kinsta.cloud and the Cloud Security Alliance. You can participate in the survey (we need your help here, so please do) by taking a few minutes at https://www.surveymonkey.com/r/RSACSADEVOPS. Feel free to tell your friends about it as well.

    security at the speed of devops

    We will be distributing copies of the report at RSA Conference, as well as digitally via devopsy.kinsta.cloud. We will also be distributing several other surprise giveaways at the event as well.

    Yes, this years RSA Conference will feature lots of DevSecOps and you can partake in all of it for free. Of course this wouldn’t be possible without the help of a great bunch of sponsors who have stepped up this year to support the events. In addition to RSA Conference, Sonatype and devopsy.kinsta.cloud, sponsors for the event are:

    Gold Sponsors

    CA Technologies, HPE, White Hat Security, Veracode, Cloud Passage, New Context and Illumio

    Silver Sponsors

    Signal Sciences, Twistlock

    See you on the 13th in San Francisco!

     

    — Alan Shimel

  • Rethinking Unemployment in the Age of Automation

    Rethinking Unemployment in the Age of Automation

    In my last article concerning the impact of automation and robotics on human employment, I asserted that commercial job loss is more a result of automation than outsourcing. Also, I asserted that this trend was going to continue at an accelerated rate. I said we need to address three areas of concern to mitigate the impact:

    • Income
    • Birthrate
    • The meaning of work

    In this installment, I am going to look at income—specifically, the need to rethink how we approach unemployment insurance.

    Let me share a piece of personal information with you. A while back I lost a gig and was eligible for unemployment benefits. The amount I was eligible to receive back in 2012 was $300 a week. (Today, the maximum benefit is $450 a week for up to 26 weeks.) In the scheme of things that’s not much money. In a major metropolitan area such as Los Angeles, $1,200 a month does not even cover my housing costs. Luckily, I was able to get another gig in no time at all. But, I am a tech worker. Others are not so lucky.

    Unemployment benefit in California is calculated by using the following formula:

    highest quarterly earnings/25

    Thus, the average programmer makes around $75,000 a year, which comes out to $18,750 a quarter. So doing the math:

    $18,750/25 = $750 a week

    But that $750 number exceeds the maximum allowance. So, if you are a programmer who has been “let go” in California, the most you’ll get is $450. Also, any benefit you receive is subject to income tax. If you find a part-time job to make up the difference, your benefit will be reduced.

    The calculation is not special to California. Arkansas is pretty much the same. In Texas you get a little more.

    If you are accustomed to making $75,000, which after taxes is about $1,100 a week, making ends meet on $450 pre-tax dollars is going to be a stretch.

    This is not a pretty picture in a few ways. First, there is the built-in incentive to not work legally. You are not encouraged to use your creativity to launch your own business. Forfeiting earned money does not encourage you to take on small jobs that allow a company to get to know you. (Try and buy has led to many a full-time position.) So what do you do? You go into the shadow economy. You work under the table: Have the check made out to your wife on her W9 or have it show up on Paypal as a gift. Is the practice shady? Yes. Is it necessary? Yep, particularly as the end of the month rolls around.

    Now, if you are in a major city such as New York, San Francisco or Los Angeles and you are in prime employment age, between 25 and 45 years old, getting another tech job quickly is usually not a problem, provided you know what you are doing. But, what do you do if you are a 50-year-old Visual Basic programmer in Glen Falls, New York, with two kids still in high school and a housing market that is anemic? You just can’t get up and move. And, learning programing technology is going to take time.  Now, imagine the same scenario, only this time you work in a small furniture factory in Alabama and your job lathing table legs has just been replaced by a robotic CNC machine. The picture is now a nightmare.

    So, what do we do?

    I am a supporter of the notion of Universal Basic Income (UBI). UBI is a system in which citizens of a given nation are provided with enough basic income to meet the essentials of life. Typical in just about all the plans for UBI is the stipulation that there are no strings attached. Under UBI, if you want make more money you can. Your UBI allowance is not decreased. UBI can be more about developing your value in society rather than living off the dole.

    Still, I am a realist. I am not of the belief that one day a magic wand will be waved over state and the national capitals, that politicians will come to their senses and amazingly we will have UBI. Big change does not work that way unless something gets blown up (Think Pearl Harbor and 9/11). I am of the thinking that when it comes to large-scale change, the best thing to do is focus on one thing. For me, that one thing is to eliminate the “payback” clause in unemployment benefit policy.

    Given that many, if not most, jobs will be automated before the end of the century, the notion that unemployment is a benefit that tides us over until the next job comes along is outdated. There might not be any next job. Rather, unemployment might be a time to reinvent ourselves. Reinvention means using the unemployment benefit as a baseline of income upon which we can build more income. We should not be penalized for making money on top of the unemployment benefit. Rather, the benefit needs to be a subsidy from which greater income grows. Once a livable level of income is achieved and a trajectory of reliable, personal revenue is established, we can revisit the size and limit of the benefit allowance. Until that time, the allowance remains in place.

    Think of eliminating the “payback” clause as training wheels for full UBI. Removing the ““payback” clause in unemployment benefit policy is a concrete first step to having realistic policies about labor and income in the Age of Full Automation. The legislative debate and public education that will happen in the course of eliminating the “payback” clause of unemployment insurance will put Universal Basic Income on the social and political agenda.

    UBI is not the stuff of fantasy. It is already has an experimental implementation is Finland. The National Digital Council of France recommends testing UBI. UBI exists in a modest way in the United States in the form of the Alaska Permanent Fund.

    As I mentioned in the previous article, using automation to replace human labor is nothing new. But, what is new is the rate at which the human labor is being replaced. If we do not start implementing concrete ways to address the long-term ramifications that result from the ongoing elimination of human labor from the commercial landscape, the storming of the Bastille in 1789, the bread riots of 1863 in the southern United States and the removal of the Bonus Army from Washington, D.C., in 1932 will look like a warmup act for what might very well transpire. Removing the “payback” clause from current unemployment benefit policy is but a small step toward addressing the issue at hand. However, put a lot of small, achievable steps together and after a while you’ve made significant progress solving a big problem.

    So here is something we can do.

    Take 15 minutes out of your day to copy the following and send it to your local and state representatives as well as your representative in Congress:

    Dear Representative _____________
    Please initiate legislation immediately to remove the practice of deducting money earned while receiving unemployment benefits from a recipient’s payment. Also, make it so that unemployment benefits are no longer taxable income.

    As automated labor continues to do more jobs formerly done by humans, unemployment insurance benefits need to be adjusted in favor of empowering unemployed workers to participate in the modern economy, not penalizing them for using any and all available resources to improve their condition.

    Thank you,

    YOUR NAME HERE

    The problem of automation replacing human employment is real and it’s not going away. The 15 minutes you spend will be well worth the time invested.

    — Bob Reselman