devopsy.kinsta.cloud

Category: Features

  • Testing and Certification in the Age of Automation

    Testing and Certification in the Age of Automation

    If we do not change the way we teach, 30 years from now we will be in trouble. Because the way we teach, the thing we teach our kids are the things from the past 200 years. It is knowledge based. And, we cannot teach out kids to compete with machines, they [machines] are smarter.

    We have to teach something unique so that a machine can never catch up with us.

    —Jack Ma, CEO Alibaba

    tl;dr synopsis

    Given the complexity of modern DevOps, technical certification is becoming more granular. Also, its use is exploding as a requirement for employment. Most technical certification is awarded by passing a test composed of multiple choice questions. Passing a test with multiple choice questions requires the test-taker to absorb a significant volume of knowledge for a short period of time. This acquired knowledge does not need to be retained. Hence, the certification can only attest to the bearer’s knowledge of a technology at the time the test was taken. And, essentially the test measures only the bearer’s ability to take the certification examine. Finally, testing by multiple choice does not ensure the certification bearer’s qualification in terms of required experience or higher-level thinking capabilities.

    Technical certification is valuable in the current commercial landscape. However, at some point, as machine intelligence is able to perform more of the activities presently done by humans, the format and methods by which certification testing is administered will need to change. Future certification testing methods will need to put greater emphasis on analysis and creative problem-solving rather than the current focus on knowledge acquisition and rote application. Also, what and how we teach humans will need to be unique, beyond the capabilities of artificial intelligence.

    Over the last 10 years, DevOps has become a much more complicated landscape. Regardless of the service provider of choice—Amazon Web Service, Microsoft Azure, Google Cloud, OpenStack, IBM, Joe’s Homegrown Cloud Service—you gotta know a lot to play.

    At a high level, service providers offer products that are surprisingly similar. For example, they all provide some sort of machine virtualization, storage services, database services, queuing technology, authorization service, provisioning technology and API management. But the way you manipulate the conceptual knobs and switches to get any of these products to work can vary dramatically between providers. There’s a lot of minutiae involved. Absorbing the amount of detail required to be productive in a provider’s product line takes time. And, ensuring that someone can actually work competently with a service provider’s products is a crapshoot. For example, a deployment engineer may understand the concepts behind dynamic provisioning, but getting a Kubernetes orchestration to work in Google Cloud is where the rubber meets the road. Doing is always much more difficult. As I said, there’s a lot of detail involved.

    So, how do companies ensure that the people they hire to fiddle with their multimillion dollar, mission-critical technology stack will deliver the goods without blowing things up? Most have an extensive technical interview process accompanied by a stringent reference check. Some just hope. Others require certification.

    The Rise of Micro Certification

    The notion of certifying that a person has the skills and experience required to be competent in a profession has been around since 1885, if not before. That was the year Massachusetts implemented the first written bar exam. Before that time, all a person needed to do lawyering was to get a note from a court saying the person could be a lawyer. That’s how it went for Abe Lincoln. Eventually the profession matured. Professional qualification was determined through a test-based approach. Early bar exams used essay questions. In 1972, with the addition of the Multistate Bar Exam, multiple choice questions were included.

    Going to multiple choice questions may seem like a trivial change, but it’s not. Whereas a knowledgeable professional is required to grade an essay question, multiple choice answers can be evaluated by anybody with the answer key. Hence, the popularity of multiple choice questions on the SAT. It’s the most efficient way to grade millions of high school test-takers each year. Evaluation is fast, cheap and a machine can do it.

    As I mentioned at the beginning of this piece, IT in general and DevOps in particular has become a place of increasingly granular complexity. There are a lot of technologies on the landscape. Each of those technologies has a significant learning curve to be overcome to achieve mastery. The conventional wisdom is that the best way to determine mastery is to test a person’s knowledge of the given technology and then measure the results of the test—high score, good; low score, bad. As with early testing practices, the fastest, cheapest way to make an evaluation is to administer a test made up of questions with multiple choice answers. This is sort of like the SATs, except most technical certification is geared to a particular vendor’s product line, not a general body of knowledge. (You can view a sample of test for AWS Certification as a DevOps Engineer Professional here).

    This type of professional testing paradigm is exploding. It’s infiltrating every corner of the technology landscape. And, more employers are requiring certification as conditions of employment, both for prospective employees and those already on staff. This would be OK, except for one thing: After you scrape away all the preconceptions and assumptions about the value of test-based certification, when it comes down to the bare-bones validity of test measurement, the only thing a test really measures is the ability to take the test. For example, a deployment engineer might be sitting for a certification test after having been up all night working to get the company back online after a system failure. The taker, who is exhausted, ends up failing miserably. Yet, some slacker just out of high school who has never seen in inside of a data center can take the test using stolen answers and pass with flying colors. Tell me, please: Who is really the most qualified professional?

    Testing by Regurgitation

    Certification is not the problem. After all, I really do feel more comfortable knowing that the surgeon about to open up my wrist to alleviate my carpal tunnel syndrome is certified by the American Board of Surgery. Rather, the problem is the way that certification testing is conducted. In my opinion, a certification testing process that emphasizes the multiple choice question-and-answer format is flawed. Even when questions are answered correctly, the test format does not really verify the competence of the taker, only that some facts are known. It’s just testing by regurgitation.

    Such testing requires the taker to absorb a lot of knowledge and then dump it out according to the test requirement at hand. There is no guarantee of long-term retention. It’s the age-old process of cramming for the test. Once the “time’s up!” bell rings, the chances are that the test taker will forget most of what she absorbed. Those with photographic memories might remember it all, but for most of us mere mortals, it’s a one-shot deal.

    Few people in tech work using the cram-it-in method. Most of us just use this thing called the internet to get the answers we need, when we need them. It’s what Bill Gates calls “information at your fingertips.” Yet, we still test for the knowledge in your head at the moment.

    There is a better way.

    A Better Way

    Certification is good provided it ensures that the bearer knows what he or she is doing. When certification is about nothing more than checking the right checkbox on an online test, there’s a problem. Put a monkey in front of a multiple choice test for eternity and eventually the animal will score 100 percent.

    So what do we do?  We do the following:

    Support Open Book Testing

    If the purpose of the test is to ensure that a person has a certain body of knowledge at the time he or she takes the test, make the body of knowledge required available at test time. It’s called open book testing. That’s how it works in real life. For example, you need a NodeJS package to provide mock objects. Do you rely upon your existing knowledge about the packages you know? Great, but what if you don’t know? Does work come to a grinding halt? No. You go to NPM to find one that meets your need. That’s how it is in real life. A competent professional is expected to have a baseline, high-level knowledge of his or her professional domain. For the day-to-day details, a pro has the ability to find accurate answers to questions quickly.

    Instead of having a certification testing process based on cramming, maybe we should eat the dog food we make in real life and go open book. There is little downside to researching what you need, when you need it. Besides, the test question created a week ago might be best answered by a new technology created today.

    Put the Emphasis on Essay Questions

    The actual mechanics of testing vary according to the level of cognition being examined. I wrote an article about this a few years back. The best way to test higher-order thinking—analysis, synthesis, evaluation—is by using essay questions. After all, what is a Ph.D. dissertation if not a very big essay question? Essays require a level of thinking that is hard to capture using lower-order test methods such as multiple choice. Essays reveal not only what the test taker thinks, but also how the test taker thinks. There’s a reason why your high school math teacher wanted you to show your work when taking an algebra test. Sometimes how you get the answer is just as valuable as the answer itself.

    A good certification test will provide a question format that allows test takers to illustrate their thinking along with the way they arrived at an answer. Thus, the need for a bias toward essay questions. Again, how you think is just as important as what you think.

    Put a Human Back in the Examination Process

    I’ll share an intimacy with you: I’m not very good at answering multiple choice questions. When confronted with one, I spend a lot of time trying to figure out what the question is really asking. You’d be surprised at the number of test questions out there that are vague and confusing.

    This was a real problem for me back when it was time to go to college and do the SAT dance. Fortunately, my alma mater focused more on my essays than my SAT score. Also, a lot the exams during my collegiate years were administered as essays or conducted as interviews with a professor. Later, when it was my time to be the Guy Awarding the Grade, my process was to evaluate students by interviewing them about one or many of the projects they did. I based my grade on the quality of the project itself and the thinking that went into the work. I tested my students by talking to them and reviewing their work. I like to think that I got a pretty accurate idea of a person’s competence, more than a multiple choice test could ever provide.

    Providing the opportunity for human interaction in the examination process can go a long way to providing the information required for making an accurate evaluation of a person’s competence.

    Require Testimony of a Candidate’s Experience, Character and Competence

    Think about this: It’s possible to be an AWS Certified Solutions Architect Professional without ever having done a day’s worth of paid, real-world work. All you need to have done is pass the certification exam. Yes, of course passing the exam is meaningful. It’s a grueling test. At the least, the test might prove that should be able to work the conceptual dials and switches that go with a given AWS service. But, as far as having the real-world experience, competence and character to play a critical path role in a mission-critical enterprise, some other instrument of certification is required. This instrument is sometimes called a reference—or, as the Wizard said to the Tin Man in “The Wizard of Oz,” a testimonial.

    As you read above, back in Abe Lincoln’s day, a letter from a court attesting the good moral character of the bearer was all that was required to practice law. You can think of good moral character as the ability to show up on time, do reliable work, demonstrate a commitment to excellence and get along with others. Such a description might sound melodramatic, but it counts.

    While it’s true that some certifications require that bearer to have a modern version of “good moral character,”  in addition to good test scores, many do not, particularly in tech. An employer wants to hire people who know what they’re doing and have the wherewithal to work effectively in an organization. Potential candidates want to provide evidence that they have what it takes to be a good employee. Building a testimonial of the bearer’s experience, character and competence into a technical certification will add a great deal of value for all involved. Also, the testimonial needs to affirm the bearer’s ability to adapt to change. In the not too distant future, your commercial value will not be about what you know today, but rather how fast you can work with technologies that will appear tomorrow.

    How to Win the Race

    For better or worse, we’re in a race with machines to keep our jobs. They don’t really want our job. They’re incapable of desire. But, that’s not to say they can’t have our job should the machine prove to be able to do it. Sadly, the current practice of technical certification is focused on passing tests concerned with the acquisition of knowledge.

    Right now, we’re winning the race. Machines still have problems with knowledge-based tasks involving advanced image recognition and reading comprehension. We still know how to differentiate between a dog, cat and an apple tree better than a machine can.

    But, it’s not always going to be this way. Keep in mind that talking machines were very primitive 20 years ago. Their voice had an artificial, staccato rhythm that was distinctly robotic. Today, it’s hard to tell the difference between a human or machine when a robocall disturbs your evening meal. It’s only a matter of time before the machine can do mid- to high-level knowledge-based work better than any human. Jack Ma’s quote at the beginning of this article supports this assertion.

    We need to change. The commercial value we’ll bring to the workplace in the future will be about analyzing, synthesizing and evaluating. Machines will be able to to the lower-level thinking faster and more accurately than we ever can. The realm of human excellence will be about better understanding the world around us and bringing new things into that world. The way we start is by teaching something so unique that the machines can never catch up. This thing is creativity. The paradox is that creativity can always be learned, but rarely be taught. Still, we must try. We have little choice not to.

    — Bob Reselman

  • Manage Cloud Clutter with Better DevOps Hygiene

    Manage Cloud Clutter with Better DevOps Hygiene

    One of the core principles of DevOps is automation. Continuous development, deployment, monitoring, security and every other element of a continuous DevOps life cycle depends on as much of the underlying tasks and actions being automated as possible. Although the provisioning, scaling and decommissioning of most DevOps resources in the cloud are handled by automated processes, inevitably there will be rogue artifacts and other cloud waste left behind.

    When we talk about DevOps, we tend to focus on developers, but the reality is that DevOps straddles development, IT operations and general business processes. It is the cross-section of these three areas and how they mesh that enables DevOps to deliver increased agility, scalability and streamlined app development and deployment when implemented effectively.

    Managing cloud costs and ensuring efficient use of resources should also be a function of DevOps. DevOps teams tend to hyper-focus on app development, integration, speed of delivery and app performance—all of which obviously are very important. It’s also important, though, to reduce or minimize infrastructure costs and ensure that cloud resources are not being wasted or left behind as remnants that are no longer being used.

    Tearing down walls between teams and breaking down silos are hallmarks of DevOps. That same approach should be applied when it comes to managing cost and cloud waste. A white paper from ParkMyCloud notes, “Consider the problem of running resources when they’re not in use and how this contributes to cloud waste. If access is limited and only one person has the ability to turn instances on and off, then one individual is solely responsible for ensuring that cloud resources are used optimally.”

    To efficiently manage cloud resources and reduce unnecessary clutter and costs, you need to pay attention to the right data. DevOps relies on monitoring and feedback to ensure apps are running as expected and performance is optimized. That monitoring and feedback also needs to look at things such as whether cloud instances are properly sized, if they’re continuing to run when they’re no longer being actively used, and whether there are rogue or orphaned resources out there that are unnecessary but still being paid for.

    Just as automation drives DevOps itself, automation can also be an effective tool for managing and minimizing cloud costs and clutter. According to the ParkMyCloud white paper, 44 percent of cloud workloads are non-production—test, development and QA environments, for example—and don’t need to run 24/7.

    “One way to save really significant dollars in dev and test is to switch your resources off when you go home,” suggested Werner Vogels, CTO of Amazon Web Services. An organization can theoretically reduce costs associated with development and test environments by up to 75 percent by simply turning those things off when they’re not needed.

    If you think about it, managing cloud costs and clutter in DevOps is essentially the same as managing security within DevOps, which is essentially the same as effectively managing DevOps. You have to consider cloud infrastructure costs as a part of the holistic environment or project; remove silos to empower everyone involved to be part of the solution; monitor key metrics to get useful feedback; and automate the process as much as possible. As with DevSecOps, the main key is to make cloud hygiene and the reduction of cloud clutter an integral part of the DevOps life cycle—not something that is tacked on after the fact.

    — Tony Bradley

  • The Origins of DevOps: What’s in a Name?

    The Origins of DevOps: What’s in a Name?

    Depending on your frame of reference, DevOps will celebrate it’s ninth or 10th anniversary this year. In 2016, RightScale’s “State of the Cloud Report” estimated that 70 percent of SMBs were adopting DevOps methods. Every indication is that percentage has increased since then. As DevOps prepares for its second decade of existence, it might be worth a stroll down memory lane to revisit the origins of DevOps methods—and even the term itself.

    Pre-2007: A Perfect Storm of Events

    Prior to 2007, a series of circumstances came together that would eventually give birth to what we know today as DevOps.

    “Lean manufacturing” was already well-established as a set of best practices for manufacturing. Often branded as the “Toyota Manufacturing Method,” lean manufacturing strives for process optimization across the manufacturing floor. (Sidebar: Toyota leaders were originally inspired by the ingenious assembly line methods introduced by Ford Motor Company.) “Continuous improvement” is the mantra for lean manufacturing and practitioners continually evaluate ways to:

    • Keep inventory at a minimum. Lean manufacturing means minimal inventory on hand: raw materials (materials used to produce goods) and finished inventory (completed products waiting to be assigned to an order and/or shipped).
    • Minimize the queue of orders. Ideally, orders received should move immediately into fulfillment mode. A key metric of lean manufacturing will always be “order to ship” time.
    • Maximize efficiency in the manufacturing process. Process re-engineering and improved automation will marry into a goal to produce goods as quickly as possible. Each station of operation along the way (cut, weld, assemble, test, etc.) is evaluated for inefficiencies.

    In IT, traditional waterfall methods of application development were already giving way to rapid, iterative methods such as agile. “Speed” was the battle cry, even if quality output was occasionally compromised in the pursuit of rapid development and deployment. Similarly, on the operations and infrastructure side of IT, Cloud Computing and, in particular, infrastructure as a service (IaaS) and platform as a service (PaaS) were coming into their own as mature service offerings.

    Finally, a fledgling set of tools classified as “continuous integration (CI)” tools began to emerge. The notion of CI tools was birthed and branded by Grady Brooch back in 1991 in his Brooch Method.

    Related Content:

    DevOps: The Innovation Power Couple

    A Definition of DevOps for the Masses

    2007-2008: A Frustrated Belgian

    Belgian consultant, project manager and agile practitioner Patrick Debois took on an assignment with a Belgian government ministry to help with data center migrations. In particular, his role was in certification/readiness testing. His duties required him to straddle activities and relationships between the application development teams and the operations teams (server, database network). His experiences—and frustrations over the walls of separation and lack of cohesion between application methods and infrastructure methods—planted seeds of discontent for Debois. His desire for a better way would soon lead him to action.

    In 2008, at the Agile Conference in Toronto, Andrew Schafer posted an offer to moderate an ad hoc “Birds of a Feather” meeting to discuss the topic of “Agile Infrastructure.” Only one person showed up to discuss the topic: Patrick Debois. Their discussions and sharing of ideas with others advanced the concept of “agile systems administration.” In that same year, Debois and Shafer formed an Agile Systems Administrator group on Google, with limited success.

    2009: The Case for Dev and Ops Cooperation

    At the O’Reilly Velocity Conference, two Flickr employees—John Allspaw, senior vice president of technical operations, and Paul Hammond, director of engineering—gave a now-famous presentation titled, “10+ Deploys per Day: Dev and Ops Cooperation at Flickr.” The presentation had a dramatic flair to it, as Allspaw and Hammond would role-play the contentious interplay between representatives of  Development and Operations during a typical software deployment, along with all the finger-pointing/blame that goes on, such as, “It’s not my code, it’s your machines!” Their presentation made the case that the only rational way forward is for application development and operations activities to be seamless, transparent and fully integrated. Over time, this presentation has reached legendary status, and is historically viewed as the seminal moment in time for that called out to the IT industry for methods that we now know as DevOps.

    Unable to attend in person, Debois watched the Allspaw/Hammond presentation by video stream. He was inspired, and—at the prompting of others through social media—formed his own conference called Devopsdays in Ghent, Belgium. By this point in time, the term “DevOps” had officially landed in the history books.

    2010: DevOps in the United States

    With a growing constituency, a Devopsdays conference is held for the first time in the United States in Mountain View, California, on the heels of the Velocity annual conference. Fast forward to 2018: There are more than 30 Devopsdays conferences already scheduled for 2018, including dozens across the United States.

    2013: ‘The Phoenix Project’

    For many of us, another noteworthy moment in the history of DevOps was the publishing of the book, “The Phoenix Project,” written by Gene Kim, Kevin Behr and George Spafford. This fictional novel tells the story of an IT manager thrust into a seemingly hopeless situation, as he’s charged with salvaging a mission-critical ecommerce development project that’s gone off the rails. His mysterious mentor, a board member steeped in the disciplines of lean manufacturing, guides the main character into new ways of thinking about IT and application development, introducing the concept of DevOps along the way.

    (Sidebar: The Phoenix Project helped inspire us to write “Outsource or Else!” a similar business fable in which a VP of Software uses DevOps when outsourcing development of a major new product.)

    DevOps for the Future

    It’s reasonable to describe DevOps as a journey, or perhaps an aspiration, rather than defined destination. DevOps, like lean manufacturing, seeks continuous improvement, seeking higher output, greater efficiencies and even continuous deployment. Automated tools that support DevOps continue to evolve.

    Much has been accomplished since the inception of DevOps in the last decade and we expect to see even more in 2018 and beyond.

    — Steve Mezak

  • Third Annual DevOps Dozen Winners Announced

    Third Annual DevOps Dozen Winners Announced

    We are very pleased to announce the winners of the third annual DevOps Dozen Awards. In many ways this year was a watershed year for the DevOps Dozen, as the process of selecting, voting and choosing the winners was much more refined and mature. In each of the 12 (it is a dozen, after all) categories the winners were absolutely deserving of the award and recognition.

    Many thanks to our all-star panel of judges: Jayne Groll, Robert Stroud, Helen Beal, George Hulme and Ericka Chickowski. I was the tie-breaker judge and had to cast a vote in just one category. I should also say that almost all of the categories were very tight. Every one of the finalists was deserving of the recognition!

    These awards are a reflection of some of the great work being done in the DevOps community. They are not exhaustive; there are many, many worthy companies, people, projects and products out there. But here is our take on the best of the best in DevOps.

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

    Best DevOps Open Source Project

    best open source solution Jenkins is the winner of the Best DevOps Open Source Project for 2017. Originally created in 2004 as a fork of “Hudson,”  Jenkins is one of jenkinsthe leading open source automation servers available. Jenkins has an extensible, plugin-based architecture, enabling developers to create 1,400+ plugins to adapt it to a multitude of build, test and deployment technology integrations. In 2017, Jenkins surpassed 155,000 active installations (these are active installations that report usage back to the Jenkins project—only a fraction of total installations), and approximately 1.5 million users, making it the most widely deployed continuous delivery automation server in the world. Learn more: https://jenkins.io/

    Best DevOps Commercial Solution

    devops dozen commercial solution ElectricFlow from ElectricCloud is the winner of the Best DevOps Commercial Solution for 2017. ElectricFlow is an enterprise-grade DevOpselectric cloud release automation platform that simplifies provisioning, build and release of multi-tiered applications. A shared, model-driven approach to managing environments and applications allows teams to coordinate multiple pipelines and releases across hybrid infrastructure in an efficient, predictable and auditable way using the tools and stacks teams already know and love. Learn more: http://electric-cloud.com/products/electricflow/

    Best DevOps Solution Provider Executive


    devopsdozen SP exec     The winner in this category was actually a 1/1a entry of the CloudBees team of CEO Sacha Labourey and CTO Kohsuke Kawaguchi. Sacha’s Sacha and KK Cloudbeesbackground prior to CloudBees was as CTO and key person at JBoss. KK was a Sun engineer when he first became involved with Hudson and later founded Jenkins. Together, they have built CloudBees into a powerhouse in the DevOps and CI/CD space. While working closely with the Jenkins community, they also have been instrumental in the continued growth and popularity of the Jenkins project. Together, they are a formidable team worthy of this award!

    Best DevOps Solution Provider


    DD best devops solutions provider     CA Technologies, which now includes Automic, BlazeMeter, Runscope and Veracode, is the winner of the Best DevOps Solution Provider for 2017. From a toolchain perspective, CA Technologies provides the widest array of highly automated solutions necessary to build and optimize integrated workflows across application development, delivery and operations. Spanning the entire application life cycle—including planning, development, testing, release and operations—only CA Technologies offers the full range of capabilities needed to deliver secure, quality applications quickly with an unparalleled customer experience.

    Most Innovative DevOps Solution of the Year

    most innovative devops solutionThe Most Innovative DevOps Solution of the Year 2017 goes to Habitat from Chef, the leader in Continuous Automation. Habitathabitat is a SaaS-based service that provides the fastest way to package apps simply and consistently for deployment and management across flexible cloud-native architectures such as those comprising Docker Swarm, Kubernetes and Cloud Foundry, both on-premises and in-cloud. Habitat gives developers and operations teams complete control over the containerized application life cycle. Learn more: https://www.habitat.sh/

    Best DevOps Evangelist


    devops evangelist    Derek Weeks VP and DevOps Advocate at Sonatype (co-founder of All Day DevOps) is the Top DevOps Evangelist for 2017. This year All Day DevOps offered 100 free onlinederek weeks sessions led by DevOps practitioners to 33,000 professionals around the world. Since its founding, the community has attracted, educated and supported more than 40,000 DevOps professionals. The conference also brought attention to more than 250 DevOps-related communities, meetup groups and organizations that are helping to educate practitioners around the world. In 2017, Derek delivered 18 DevSecOps-related keynote addresses, conference speeches and meetup presentations in the United States and Europe. He also produced more than 75 DevOps-related blogs over the year, covering topics from continuous delivery to DevSecOps, modern infrastructure and cultural transformations. The blogs not only delivered first-hand experiences, but also highlighted the work of more than 40 DevOps practitioners from different companies around the world.  The blogs can be seen at Sonatype, All Day DevOps, devopsy.kinsta.cloud and Dzone. In addition, Derek championed a number of DevOps reports and surveys in 2017, including the “State of the Software Supply Chain Report” and “2017 DevSecOps Community Survey,” to shed light on industry best practices and areas in need of attention or evolution.

    Best DevOps Transformation


    devops transformation    CapitalOne was the judges choice for Best DevOps Transformation for 2017. Over the past few years, the 20-year-old financial services giant capital onehas been transforming itself, tapping DevOps to establish a continuous software delivery cycle. Topo Pal, a senior director and senior engineering fellow, told a packed room at the recent DevOps Enterprise Summit in San Francisco the company’s journey suits its entrepreneurial spirit. “We consider ourselves a startup, and like any startup, we have different DNA,” said Pal. “For instance, we build our own software.” All the better for adopting DevOps. The company does just about everything (including back-end processing) in the public cloud now, with a focus on building microservices using open source technologies. Having spent the previous three years building out automation steps, scaling DevOps, adopting open source and cloud and starting to measure its success, Capital One is now turning its attention to continuous delivery. Learn more:

    Best DevOps Transformation Leader


    devops transformation leader    Paula Thrasher is the winner of the Best DevOps Transformation Leader for 2017. Paula is Director of Digital Services at CSRA Inc. Paula paula thrasher Thrasher has 20+ years experience in IT and has spent the last 15 years trying to implement Agile culture in the federal government. Her first Agile project was in 2001; since then, she has led more than 15 programs and projects as an Agile developer, technical lead, Scrum master or Agile coach. Her teams have helped two federal agencies migrate applications to Amazon AWS GovCloud and done some other amazing DevOps ninja work along the way. Paula is also the executive lead for CSRA’s corporate giving group’s search for a STEM charity and joined forces with Girls Who Code to bring summer programs and after-school clubs focused on closing the gender gap in IT. She also participated in the DevOps Forum 2017, co-authored a paper on DevOps learning in organizations,”Continual Learning: Building a DevOps inspired Career Track,” and peer reviewed other paper topics produced by the forum this year. Paula has spoken publicly at multiple industry conferences including AllDayDevOps  2017, Red Hat Government Symposium and DevOps Enterprise Summit 2017.

    Best New DevOps Solution Company

    nClouds is a provider of DevOps and cloud services, products, and solutions, specializing in modern infrastructures on AWS — and winner of Best New DevOps Solutions Company for 2017. They work as an extension of their customers’ teams to build and manage modern infrastructure solutions that deliver innovation faster. nClouds is a certified AWS Advanced Consulting Partner with 250+ DevOps AWS implementations, 500+ deployed pipelines, and 10,000+ managed servers. They call their new SaaS offering, nOps, modern change management at the speed of DevOps. nClouds was named to CIOReview “20 Most Promising DevOps Solution Providers – 2017” and “20 Most Promising IT Service Management Providers – 2017”.

    Best DevOps Book/eBook

    best DevOps“The DevOps Adoption Playbook” by Sanjeev Sharma of IBM won the Best DevOps Book Award for 2017. The book lays out a clear “how-to” devops adoption playbookfor DevOps, including topics such as value stream mapping, how to lead the transformation of culture and scaling DevOps to the enterprise. As Sanjeev himself says, the book started from a Powerpoint deck of best practices he created to take in everything he had learned.

    This book represents the culmination of years of learning by not only Sanjeev, but by IBM in general, and includes some of the leading names in DevOps that he learned from during this time. Sanjeev also stays true to the “playbook” paradigm, making references to cricket, soccer and other sports throughout. It is a good read and well-organized. To learn more, listen to this DevOps Chat: ‘The DevOps Adoption Playbook’ by Sanjeev Sharma.

    Best DevOps Presentation of the Year

    devops presentation“DevOps: The New Reality for Enterprise Transformation,” a 45-minute keynote presentation at IBM InterConnect 2017, is the winner of the Best DevOps Presentation for 2017. It features Gene Kim, John Comas, NBCUniversal and IBM execs and  distinguished engineers including David Lindquist, Angel Diaz, CJ Paul and Michael Elder. Are you dabbling in DevOps? Maybe you’ve run a great pilot project or have a terrific two-pizza team that’s innovating new apps. How do you scale their success to your whole organization? The answer lies with a combination of cultural, personal and technical transformations that blend methodologies and cloud-native approaches with proven automation patterns and existing on-prem development. The presentation includes client stories and demonstrations of the latest IBM solutions to help companies transform their teams and build, deploy and manage their apps for large-scale enterprise IT environments.

    Best devopsy.kinsta.cloud Article of the Year

    “Continuous Integration vs. Delivery vs. Deployment: What’s the Difference?” by Chris Tozzi won the Best devopsy.kinsta.cloud Article of the Year devopsy.kinsta.cloud articleAward for 2017. Christopher Tozzi has covered technology and business news for nearly a decade, specializing in open source, containers, big data, networking and security. He is currently Senior Editor and DevOps Analyst with Fixate.io and Sweetcode.io.

    Again congratulations to the winners—well-deserved recognition for all of your efforts.

    For those interested in next year’s DevOps Dozen, information will be out in July or August of this year.

    — Alan Shimel

  • The Case Against Human Employment in the Age of Automation

    The Case Against Human Employment in the Age of Automation

    A few months back, the small Japanese restaurant down the street from me was renovated. The owner redesigned the layout of his business to solve a vexing problem: How to stay in business when faced with a continuing pattern of employees not showing up for work.

    The layout of his restaurant went from this:

    Figure 1: The pre-automated local Japanese restaurant

    To this one:

    Figure 2: The neighborhood Japanese restaurant after automation

    The new layout eliminates the need for servers. It turns out, the people he hired to take orders and bring food from the kitchen to a customer’s table just weren’t showing up for work. We’re not talking one or two random no-shows; rather, it was habitual behavior among the workforce he hired, mostly high school grads and college students. Each day was turning into a crapshoot. He’d get a text an hour or two before the beginning of a shift reporting some other excuse: sickness, lost dog, whatever. Usually, the note closed with the inevitable, “Sorry, won’t be in today. See you tomorrow.”

    So he automated.

    Related Content: An Unanticipated Obstacle to Full Automation

    The new design is working out well. You come in. He directs you to a table. There’s a touch-screen monitor at each table diners use to place their order. The orders go directly to the kitchen, which is separated from a row of tables by a glass partition. When a dish is ready, the owner (who also happens to be the chef) or an assistant passes the food out to the diner’s table under an opening at the bottom of the glass (see Figure 2, above). At the end of the meal, the owner meets you at the front station where you pay the bill. No more wait staff. No more cashiers. No more “I can’t make it today” texts.

    Automating to Stay in Business

    Removing the servers and using automation was not an easy decision for the owner. His business is not some large-scale, multi-unit corporate enterprise looking to automate away human labor to increase profit margins. This guy has worked seven days a week for 10 years to build his business into a mainstay of the neighborhood. He prefers to employ humans but he can’t. He’s automating because the available human labor is unreliable. He believed that using such an unreliable workforce would eventually put him out of business. He really needed to make the change.

    So he did.

    No Employees, No Employee Retention

    So far, things are going well. However, now the kitchen staff is beginning to join the No Show Club, despite the fact that he is hiring kitchen workers at a rate of $14 an hour—a good wage for kitchen work. What’s causing people to go MIA? Maybe it’s the product. After all, how many California rolls can you make before going nuts out of boredom? Maybe he’s difficult to work for. And I doubt they’re jumping ship to work at Mickey D’s; the Golden Arches is only paying $10 an hour. In any event, the owner has a employee retention problem that, my guess is, he’s going to solve using automation.

    What Does This Have to Do with DevOps?

    At some point, every human being becomes unreliable. Some have poor work habits, but most simply are being human and humans make mistakes. That’s how we’re built. Some of us make a few mistakes, while others make a lot. But, we all make mistakes. Most of us learn from our mistakes, and we still make others. Our human nature to make mistakes makes us inherently unreliable.

    Machine intelligence doesn’t have this problem. It will get things right, eventually. And then, once operating reliably, it’s rare for that intelligence to revert to a state of unreliability. A human can become unreliable at any point in time—taking a sick day, resigning from the job or all the mistake-making that comes with learning a new skill or technology.

    We in DevOps have a lot in common with the owner of my neighborhood Japanese restaurant. Most of us have worked really hard to keep our customers happy and coming back, well beyond the typical 40-hour work week. For the most part, we’ve been successful.

    Our success increases demand. When demand goes up, the complexity of our work increases, as does the need for more reliable operations. But at some point, our inherent human unreliability kicks in. We make mistakes. To keep things going reliably, we automate. Then we move on to the next thing. Fortunately, for the foreseeable future, there will be a “next thing” to move on to.

    Still, intrinsic to our work is a motivation to eliminate human labor from the technical landscape. We have no evil intention. We just want to do the best job possible. Given the choice between a script and a human doing the work, we’re going to choose the script every time. The script will evolve to 100 percent reliability. The human won’t.

    As I said, for now, it’s not really a problem. There will be a next thing to move on to. And, in terms of my neighborhood sushi joint, maybe the out of work no-shows will get the message about the value of showing up at a job on time and ready to work. Or, maybe they won’t. Maybe as automation becomes the standard of labor fulfillment for repetitive work, immature workers will never be given the opportunity to get the experience they need to enable them to master basic employment skills. After all, they’re human and some point will become unreliable. So why hire them at all? Why not get a few computerized gizmos to do the redundant work and then focus on keeping customers satisfied and staying ahead of the competition?

    Having no employees translates into having no unreliable employees. A business without unreliable employees is an efficient business. Efficiency in business is what it’s all about.

    And this, my friends, is the case against human employment in the age of automation.

    — Bob Reselman

  • Cloud Generation Firewalls are the New ‘Next Generation’

    Cloud Generation Firewalls are the New ‘Next Generation’

    There’s a new kid on the block—or a new firewall, at least. Traditional network and security technologies generally don’t translate well to a cloud environment. Next-generation firewalls might have been “next generation” when they were introduced, but now they’re “previous generation”—legacy technology that isn’t capable of doing the job effectively in the cloud. The new “next generation” is the cloud generation firewall.

    I’ve never been a fan of using the term “next generation” as a label. Where do you go from there? I mean, I love “Star Trek: The Next Generation, but what is supposed to come after that—”Star Trek: The Next Generation After That One”? It’s going to seem silly in 10 years when we’re talking about the archaic, outdated “next generation” technologies.

    Thankfully, we might soon be able to retire one of the “next generation” labels. ZScaler sort of started down this path when it introduced the “world’s first cloud-based next-generation firewall” in 2015. Barracuda recently took it a step farther, dropping the “next-generation” and announcing cloud generation firewalls.

    Cloud Generation Firewalls

    Aside from a catchy new name that’s good for marketing, though, what does that actually mean? Traditional firewalls, including next generation firewalls (NGFW), were engineered to protect a centralized data center or network, or a distributed network spread out over multiple locations. The public cloud is a very different environment.

    At face value, a distributed infrastructure with multiple locations connected across the internet seems similar to a cloud environment. A public cloud environment is much more dynamic, though, and has a more loosely coupled architecture than a dispersed private network. Companies move to the cloud to take advantage of DevOps, automated deployments, elastic scaling and other elements that enable them to develop and deploy applications and services more efficiently, but legacy security tools including NGFWs can’t protect effectively in the cloud.

    As with other network and security solutions, companies need firewalls that understand the cloud. To be effective, a cloud generation firewall should be cloud-native and integrate with cloud management and monitoring tools. It also should be able to automate deployment and scaling, and offer APIs that enable it to work with DevOps development tools. Finally, its licensing and pricing should reflect the dynamic nature of the cloud environment.

    Challenges of NGFW in the Cloud

    I spoke with Tim Jefferson, VP of public cloud for Barracuda, about cloud generation firewalls. He agreed that companies are facing challenges as they embrace the public cloud and try to use tools that were optimized for data center architectures in cloud environments.

    The design principles of an NGFW are “anti-pattern” in the public cloud, he said. The public cloud environment is based on keeping things loosely coupled and easily scalable, while NGFW solutions are designed for tight coupling with ties back to centralized policy enforcement.

    What’s more, he noted the licensing model for a traditional NGFW poses a problem in the cloud. Traditional licensing forces customers to deploy only in production environments, when security best practices suggest automating security architectures in all stages. Customers want to—and should—deploy security in all stages of development to better support DevOps principles, and cloud-generation licensing enables this.

    Cloud-native solutions need cloud-native licensing that takes into account the rapid scalability and dynamic nature of the environment. Barracuda went with an approach that meters based on bandwidth rather than time, so customers are billed only when the cloud generation firewall is used, not when it’s just sitting idle.

    Naming conventions aside, cloud generation firewalls just make sense. Many organizations fall into the trap of moving to the cloud and thinking they can just use the network and security tools they already have—just in the cloud. The reality is that you need cloud-native tools to effectively take advantage of the reasons you’re moving to the cloud in the first place.

    And, if cloud generation firewalls catch on, perhaps we can move beyond “next generation” and stop using that dumb term.

    — Tony Bradley

  • AI Delivering on the Business Analytics Promise

    AI Delivering on the Business Analytics Promise

    There’s a revolution underway in data analytics that could create a competitive advantage for companies that jump on it. C-suites, take note: AI-powered business analytics is finally delivering future-facing data points that CEOs need to guide their businesses to the sweet spot.

    The artificial intelligence (AI) technologies machine learning and deep learning are being used today to power through mountains of big data, much of which is previously inaccessible unstructured data such as text, video, customer reviews and customer feedback. Data scientists analyze the trends the machine learning uncovers, resulting in human-vetted, AI-derived, predictive analytics that provide strong decision support.

    Companies using AI-enabled business analytics are seeing positive results, yet most believe we’re just at the tip of the iceberg in utilizing AI’s capabilities in decision-making. Indeed, almost 70 percent of the CIOs who responded to a recent survey said they believe decisions made by machines will soon be more accurate than those made by humans.

    “Machine learning and deep learning have fundamentally changed enterprise data analytics,” said Tom Wilde, CEO of machine learning solution provider indico. He pointed out that a large majority of data is unstructured; in fact, according to some measures, as much as 80 percent of enterprise data today is unstructured. “In many cases, the unstructured data is where the real signal can be found,” and, as such, AI identification and categorization techniques can be used to develop analytics that could be used to improve a company’s product, predict future sales, identify cross-selling opportunities and reach new markets.

    “Machine learning supercharges business analytics and data science,” said Scott Zoldi, chief analytics officer at FICO. Machine learning algorithms explore relationships and data that even the best data domain expert may not think to explore, but, properly used, “Machine learning augments data scientists to make their discoveries seem superhuman. Data scientists that use machine learning will ultimately drive differentiated business value for their organizations.” In other words, AI is like using newly invented night-vision glasses for deep dark data—it should give a company a tactical advantage.

    What C-Suites Should Know about AI and Analytics

    AI and business analytics may seem like a panacea for what ails a business. But it’s not a plug-and-play technology—AI requires constant care and feeding to churn out the trends behind the data. Here are three things the C-suite must understand before adopting AI as a business driver:

    1. AI in its current form is unlikely to replace a human being. It has transformative power, yes, “but AI is going to further a lot of progress that’s already in place, not necessarily upend everything,” said AJ Abdallat, CEO of AI firm Beyond Limits, an AI company. AI will be used to create great things in years to come, but it’s not a magic bullet, it’s not infallible and it requires humans in great measure today. People should not be concerned about their jobs, nor should there be any expectation that AI might save money on personnel. These cultural concerns, along with a not uncommon resistance to change, are one of the barriers to entry.
    2. If your company punted on digital transformation, you’ll probably need an outside vendor to help you foray modestly into artificial intelligence. “The sooner you can modernize your digital infrastructure, the sooner you can bring AI in to address your [larger] business issues,” said Abdallat. In many ways, the ability to employ machine learning and AI may wind up being looked at as one of the main positive outcomes of digital transformation. Working in concert, these technologies are probably your best protection against sudden disruption by a digital-native startup with good ideas.
    3. “Too many CEOs delegate AI to their innovation teams, who conduct small-scale experiments. It’s important for CEOs to bring their own AI vision to their organizations,” said Gurjeet Singh, executive chairman and co-founder of Ayasdi. CEOs need to apply AI to the most pressing problems facing their businesses. “The world is going to change far faster than they can grasp. They need to set course immediately.”

    Adopt AI Soon

    One thing that has become clear as more companies join the AI fray, either as purveyors or consumers of the technology: The time for digital infrastructure improvements and adoption of AI is now. That said, the scope of enterprises that have already adopted AI is comparatively narrow. Companies currently using artificial intelligence to explore big data include the obvious: Amazon, Apple, Citi, DoCoMo, Facebook, Google, HSBC, IBM, Lockheed, Microsoft, Mt. Sinai, Tesla and Twitter. Many other companies are experimenting with AI in one facet of their business.

    How significant a trend will the use of AI by enterprises be? Is it at the scale of networking, the internet and cloud computing? “AI will have the same or greater impact on businesses for the next 20 years,” Wilde predicted.

    “Part of me wants to quash as much of the AI speculation as possible. The hyperbole,” Abdallat added. “But frankly, I do think that AI is potentially more transformative [than the internet, cloud etc.] … I know I’m a little biased in this, but we might be entering the era of the cognitive corporation, when man and machine at all levels of the enterprise will [cooperate] to solve problems, each learning from the other.”

    — Scot Finnie

  • The 5th Industrial Revolution: When It Will Happen and How

    The 5th Industrial Revolution: When It Will Happen and How

    Industrial revolutions have always dominated and changed the world in a big way. The first one happened way back in 18th century, and the second industrial revolution occurred almost two centuries later, in the 20th century. The third one happened only a half-century later, while the fourth one was observed within three decades. By the speed these transformations are occurring, a fifth industrial revolution is already around the corner.

    The next technology revolution will be faster and more scalable, and will be adopted by a lot more people as compared to the previous ones. Everyone on the planet will undergo a “personal” revolution by the kind of technology at their disposal. 3D-printing, wearable technology, robots. driverless cars … everything will be readily available and will make lives simpler and faster. With every industrial revolution brought a substantial increase in the GDP, and lifestyles improved manifold. The next revolutionary technology, however, does not aim to simply improve the lifestyle or help people make more money; rather, it focuses on the higher form of intelligence. Now humankind is ready to take the big plunge and step into space. With ideas such as SpaceX and affordable space travel, a future that we cannot imagine today might be possible tomorrow.

    The definition of industrial revolution includes the use of sophisticated machinery to make the work of humans easier and faster. Today, that includes robotics, machine learning, artificial intelligence and a lot more things that nobody could think would become a part of industrial revolution someday.

    In future, we can only expect technology to become more superior and sophisticated in every sense: augmented reality, big data, virtual reality, artificial intelligence and the most disruptive one—cryptocurrency—are a few to name. Cryptocurrency is something so revolutionary that it is making news every day. Bitcoin’s price is touching the sky and investors of cryptocurrency believe that the prices are sure to touch the moon in coming years. With the number of people investing in cryptocurrency and people holding on to their alt-coins, one thing is sure: A fifth industrial revolution has “already” arrived.

    Industry not only runs on machinery or ideas, but also on money. Today, people are spending their hard cash and fiat currency to buy cryptocoins, including Bitcoin, Ethereum, Litecoin, Ripple, Monero, Dash, Golem IOTA and even tokens (ICOs). A popular crypto-exchange claims it adds more than 30,000 new user accounts every day—a number not to be ignored!

    It is true, cryptocurrency currently is not regulated or controlled by any government, but it’s possible governments could impose taxes on the income generated from it in future. There is still much to be worked out in making cryptocurrency a validated form of currency. But even high-end investors such as Warren Buffet claim cryptocurrency is here to stay, and it is indeed something that will bring a bigger revolution than expected.

    The Fifth Industrial Revolution is poised at the cusp of a future in which things considered unimaginable today become the norm, and concepts such as universal basic income (UBI) help ease the sting of automation and mass unemployment. Mankind is ready to take a step forward.

    The world currently is in a disruptive stage, as the fifth industrial revolution unfolds to impact our lives—for better or for worse. Now we wait and observe what the future has in store for us.

    About the Author / Emma Rundle

    Emma is a professional content writer currently providing her freelance services to Edubirdie. Emma’s favorite topics to cover include business, software, high tech, and web development. She has a Master’s degree in Economics from The University of Texas at Austin. Follow Emma on Twitter.

  • Making Software Maintenance Cool Again with DevOps

    Making Software Maintenance Cool Again with DevOps

    What makes DevOps so important? Part of the answer lies in how DevOps encourages more appreciation for and investment in software maintenance.

    Traditionally, the IT industry has been like the construction industry. People who design new things (architects or software developers) are at the top of the value hierarchy, whereas the folks who build and maintain them (construction workers and IT Ops admins) are not held in such high esteem.

    This isn’t to say people hate admins, of course (or construction workers, for that matter). What I mean is that the work of building and maintaining tends to be seen as less creative and exciting—and ultimately less important—than the work of designing new things.

    This is why software developers in the pre-DevOps world got most of the glory. They created new code that did exciting things.

    Meanwhile, admins on the IT Ops team were stuck deploying and maintaining that code—and occasionally cleaning up messes created by developers who wrote bad code. Admins were also the first folks to take the blame when something went wrong.

    This isn’t to say that developers cause all the problems, of course. Some mistakes can be attributed to admins. Others are the result simply of poor communication between developers and admins.

    Still, in general development work—which involves creating new features and innovations—was what was celebrated. Maintenance work performed by IT Ops was less glorious.

    DevOps and Software Maintenance

    One of the most important—yet also most underappreciated—results of the DevOps movement is that it has made software maintenance cool again.

    In addition, DevOps provides more organizational support for maintaining software, while also facilitating the type of communication between developers and admins that leads to better maintenance.

    DevOps does this through principles such as the “you build it, you own it” mantra, which stipulates that whoever writes code is also responsible for deploying and maintaining it.

    Even if your organization doesn’t adopt that particular DevOps practice, it probably still seeks greater collaboration between developers and IT Ops. As a result, when something breaks in production or needs to be upgraded to maintain reliability, developers are involved, too.

    Celebrating Software Maintenance in DevOps

    Despite the emphasis that DevOps has brought to software maintenance in practice, you still don’t hear a lot of talk about maintenance work in the DevOps world.

    In essence, coding is still seen by many people as the coolest type or work that is done in the DevOps world. What DevOps has done is break down the silos separating those who code from those who maintain. It hasn’t necessarily made maintenance itself the object of more excitement.

    It may be time for that to change. Forward-thinking organizations should recognize that software maintenance—which includes tasks such as applying updates, monitoring applications and scaling host infrastructure—is just as crucial for a seamless application experience as the applications themselves. This should become an explicit part of the DevOps conversation.

    — Chris Tozzi

  • When is Big Automation Too Big for Comfort?

    When is Big Automation Too Big for Comfort?

    There’s a joke traveling around the tech-o-sphere that goes like this:

    How many software developers does it take to change a lightbulb?

    Answer: None, it’s a hardware problem.

    In the world of modern DevOps, physical infrastructure has been abstracted to code. I can count on my fingers the number of people I know who have done a physical memory upgrade in the last year. Fortunately or unfortunately, depending on your outlook, I am one of them. Nonetheless, for the most part, hardware left the building a long time ago, no pun intended. All that remains is the laptop we use to move the bits around.

    However, for those who don’t sling code, the world of automation is much bigger than our software-centric view. Most of us are aware that today there is hardware that can roam around our living room unassisted and vacuum up dirt from the floor. There’s 3-D printing, which is a technology my dentist uses extensively to fabricate crowns in the privacy of a closet next to an examination room in his office. And of course, the driverless car and truck is predicted to soon be a regular part of our day-to-day landscape.

    But, this is the small stuff. There’s a lot of hardware automation that goes well beyond the dimensions of consumer appliances and room-size automation technologies being used in factories. In fact, machine automation is becoming gigantic, as in Godzilla-size, particularly in mining.

    Mining: Let’s Eat a Mountain

    Equipment has been essential to mining since the first days when a man was sent into a cave with a pick and shovel to extract ore. Mining has come a long way since then—today, it’s a gargantuan undertaking that has become more incredibly machine-intensive. Whereas, in the past, we’d send men into a shaft in the ground to get the goods, these days, we just let a machine eat the ground, literally.

    The Bagger 293, shown below, is a bucket-wheel excavator. The 315-foot-high machine can dig a 8.5 million cubic feet of earth per day.

    bagger-293

    The Bagger 293, with a height of 315 ft, is taller than the Statue of Liberty

    To give you a sense of how big this whole operation is, first understand that, 315 feet, the height of the machine, is approximately the equivalent of the height of the Statue of Liberty, from ground to torch top. The amount of dirt that the machine can remove in a day is equivalent to digging an eight-level sub-basement beneath the floor of the Roman Colosseum. The Bagger has been in use since 1995, and no matter how you cut it (again no pun intended), that piece of iron has eaten a lot of dirt.

    Presently, the Bagger requires a crew of six to operate. But, if trends keep steady, it’s only a matter of time until machine excavators of this size can operate autonomously.

    Sound far fetched? It’s not, really. The Komatsu AHS already has a mind of its own.

    The Komatsu AHS is an autonomous earth-moving vehicle that can move a payload of 290 tons. The machine is the size of an average house.

    komatsu AHS

    The Komatsu AHS (right) is an autonomous earth moving machine

    In the past, it would have taken a small army of men weeks, if not months, to mine raw materials. Today, using technologies such at the Bagger 293 and the Komatsu AHS, the work can be done with a workforce of six. And, in the not-too-distant future, the work will require no human intervention whatsoever.

    So we’ll have machines that can get massive amounts of dirt out of the ground and move it around without the need for any human intervention, But, once mined, where does it all go?

    Hold that thought. The answer is coming.

    There’s More to Container Automation than Kubernetes

    Yara, a shipping company out of Oslo, Norway, in partnership with Kongsberg, a maritime engineering group also out of Norway, has created an autonomous container ship, the Yara Birkeland, that is set to hit the high seas in 2018. This ocean-going vessel will be manned by a crew of none. It’s completely driverless.

    Yara Birkeland

    The Yara Birkeland, to be completed in 2018, is a zero-emission, autonomous container ship that is estimated to remove up to 40,000 truck journeys

    According to the Bureau of Transportation Statistics, more than 19,000 vessels entering U.S. ports in 2010 were container ships. That’s 31 percent of total maritime activity on American docks that might very well see the elimination of seafaring crews.

    Container shipping is useful because it allows for the easy transport of goods from a variety of shippers. In the past, dockside longshoremen loaded individual bails, crates and barrels into the hold of ships by hand using winches, conveyors and stackers. Container shipping made it so the shipper loads a container and then a machine loads the container onto the ship like stacking Legos. One human does the work of dozens.

    Mining transport does not have the burden of having to accommodate a variety of goods in different sizes and shapes. There is only one product: raw ore. Thus, it’s quite conceivable that an autonomous container ship, maybe one the size of four soccer fields, can be repurposed as a giant, seagoing container holding nothing but a single product: unprocessed ore.

    So, let’s look at the dynamics of the supply chain overall. In the not-too-distant future, a machine will roll up to a mountain. It will start to eat the mountain, spitting out dirt one gigantic mouthful at a time into the bed of an equally gigantic, autonomous dump truck. And that dump truck will unload its contents into the hold of an autonomous, seaworthy vessel that very well might take the contents to an automated mineral refinery for processing.

    Those of us who have had to change a lightbulb recently understand the implications. They’re profound. Those of us still trying to figure out how to program our smart home to do the light bulb-changing might need a bit longer to catch on. But, the notion remains: If we can create a machine the size of a building to act on its own, how long will it be until we are creating building-size data centers that can act on their own? Automation on such a gigantic scale is not only possible, it’s inevitable. Controlling an out-of-control home vacuum is one thing. But, what happens when something on the order of a Bagger 293 goes beserk?

    I don’t know. But I can guarantee you that it will not be business as usual. The good news is that the Bagger only moves at about a mile and a half a day. But still, if it learns how to speed up, then might we one day wake up to find our favorite hiking hill gone due to the whims of an independent intelligence that cares not or knows not of our love of nature? What then?

    As they say in the terrain, forewarned is forearmed.

    — Bob Reselman