devopsy.kinsta.cloud

Tag: code

  • Jobs-as-Code: The Business Processing DevOps Forgot

    Jobs-as-Code: The Business Processing DevOps Forgot

    Developing web and mobile apps is cool. But in the words of a longtime ballad: “Don’t forget who’s taking you home and in whose arms you’re gonna be …” It’s the back-end services that underpin a lot of those cool apps and make them possible. So yes, servers and relational databases and enterprise applications and sometimes even mainframes are definitely a thing. And in those environments, scripting, batch processing, application integration and operational visibility are a very big thing that, more often than not, is managed by workflow and job scheduling tools.

    I argue that the “something—application, code, other” elements used to deliver all those capabilities are logically part of the application and should be treated as such. The fact that “process X” needs to start only after certain data has arrived, been cleansed and inserted into some database is just as much a part of the application as calculating an invoice amount or determining that inventory needs to be replenished.

    And if you are still reading, then I submit that you need jobs-as-code.

    Simply stated, jobs-as-code means that the jobs—automation rules for business applications—you need to manage and execute systems of record, back-end application components and data pipelines in production are built and managed in the same way as Java, Python, C++ or any other business logic code. In other words, everything that is part of the application should be included in the software development life cycle (SDLC).

    Of course, that statement is pretty simple to say but not that easy to accomplish, because traditional workflow, job and batch processing solutions have lived (and most continue to) in the operations world. The practitioners of enterprise scheduling tend to prefer graphical interfaces with a strong emphasis on ease of use and rigid control over access. Traditionally, capabilities such as developer self-service, automated build and test and deploy have not been high on most enterprise job scheduling new feature requirements wish lists. Most commercial solutions, if they do anything, add an API or two and consider the job done. Open-source authors build tools that cater to developers with little to no regard for the multitude of other user types that rely on batch workload.

    The resulting state in the industry is that developers spend lots of time building “snowflake” operational plumbing which may be difficult to test, difficult to embed in an automated delivery pipeline and either has to be reworked to make it ready for production or becomes an albatross around the necks of operations teams trying to keep it running. It’s time for the DevOps community and the industry to recognize there is a better way and we all instinctively know what it is.

    Jobs-as-Code

    To understand jobs-as-code, let’s examine the traditional dev-to-ops handoff from a developer and DevOps perspective.

    I write some code and now I want to test. The execution is simple; I want to pull some data from a relational back end, run my code to manipulate the data and push the result set to some other location to serve as a data source for a different application. I need a SQL query, run my Java code and ftp or sftp the result.

    I’ve used some interactive tool to extract my test data, debugged my code in Eclipse and just browsed the output with Notepad++. Now I want to construct a flow that either I or any of my teammates can run whenever they want.

    Today, I probably brush off my scripting skills, bash or perl or whatever, and write a quick script to run a SQL query, run my java code and then run the file transfer. Easy, right?

    Maybe not.

    Connecting to the database interactively was so trivial I didn’t even think about it, but doing it in the script is a whole different exercise. I’ve got to get my quotes and escape characters right; I have to make sure I connect without compromising the credentials needed to log in to the database; I even have to figure out what return codes I’m getting and what to do with them. Of course, I need to add some notification so that I’m informed if there was a problem.

    OK, got all that done. Now running my Java code is a piece of cake right? Well, it is when running on my machine with my credentials but maybe my teammate has a different environment. Or he’s a .net guy and doesn’t have Java configured the same way as me. Or worse, maybe doesn’t even have it installed. Better add the code to check for all these problems and notification for that, too. And when I get that failure notification, what do I look at to figure out what went wrong? I’d better pipe everything to a log and make sure others can view the log, too, so I make sure I put it on a shared filesystem that others can access.

    Let’s not event start on the file transfer! Or, when you have to add additional steps or when you have to run this a 3 a.m. as part of some testing that another group is doing or making sure that database you rely on is up and running, etc., etc., etc.

    Eventually, after way more time than I ever thought it would take, that massive script is done. I run it through some test cases and I’m done.

    On to the rest of the delivery phases with more testing and probably some more extensions that make the script truly epic.

    In those last few stages of getting to production, someone may raise the issue that this new application interacts with some other application that’s managed by some production automation tool. OK, let the rework—or, really, brand new unplanned work—begin. The developers aren’t familiar with the tool and the tool administrators aren’t familiar with the application so you can imagine how well those conversations go. However, they are all professionals and eventually manage to get the job done and the application proceeds to production.

    If this long, drawn-out story didn’t already make you uneasy, you may have caught the huge fail that is now just waiting to blow up in our proverbial faces. Most, if not all, the testing was already completed. The new work done at the eleventh hour gets minimal, if any testing, is deployed and—surprise!—has a high failure rate in production.

    To add insult to injury, somewhere down the road after all the heroics of getting the application deployed are long forgotten, a failure occurs, as is only natural and to be expected. The poor on-call folks must negotiate through that production tool they aren’t familiar with and isn’t part of their world. And then they encounter that massive, epic script. What’s going on inside of that thing and where did the failure occur? Where are the logs and do we even have all the ones we need? And saving the best for last, after the problem has been identified, how do we restart this process in the middle when half of the processing was already completed?

    So What Would Nirvana Look Like?

    What if you could create a database query by just coding the SQL statement(s), picking the database you wanted from a list of logical names and requesting notification in case of error and you could express those requirements in a few simple statements? If you want to run it at 3 a.m., you just add that requirement too and then say “run.” The availability of the database is checked, the credentials are secure, there is no scripting, log and output are captured automatically (not just from this run but as many runs as you want, and you can compare one run with another, etc.) and you get whatever notifications you requested. The logic would be solid because it’s been in use for years by organizations like yours, rather than being written under pressure while trying to meet a deadline.

    You could write your automation rules (jobs) in some simple notation you were already familiar with such as JSON, store it together with your Java code in git or whatever SCM you use. The jobs could be packaged with the rest of your application and your build, config management and testing tools and could push your entire application including your jobs through the entire delivery pipeline so there are no surprises or additional work required before deploying to production. The facilities to deliver operational visibility, support problem analysis and log and output management would be second to none because they have been evolving with input from community and IT professionals.

    Imagine if this magical-sounding solution that implemented Jobs-as-Code was available from github and other public sources? You could download, install and have access to Jobs-as-Code in minutes. You wouldn’t have to submit access requests to IT folks, no purchase requisitions, no messy and complex installations.

    You don’t have to imagine. Jobs-as-code solutions already exist. If the tool(s) you’re using doesn’t give you these capabilities, switch! At least start talking to your peers and let them know the better way has arrived. With sufficient demand from the community, the vendors and authors implementing the myriad job management tools may just accommodate you.

    — Joe Goldberg

  • All Day DevOps: Modern Infrastructure Automation

    All Day DevOps: Modern Infrastructure Automation

    “We’re no longer an airline. We’re a software company with wings,” claims Veresh Sita, CIO, Alaska Airlines. The success of today’s businesses rests on software. It is an integral part of infrastructure, so we need to always ask, “How can it be better? More reliable? More secure?”

    Nathen Harvey (@nathenharvey) is the VP of Community Development at Chef and the co-host of the Food Fight podcast. He is also an evangelist of automating software operations, which is what he presented on at the 2016 All Day DevOps conference.

    Nathen started his talk by stating that “automation at scale is required for high velocity IT,” making the point that in today’s environment, you can’t wait months between deployments. Enterprises are moving to continuous integration/continuous deployment, and he advocates for continuous automation.

    harvey pic1.png

    To implement automation at scale, you have to start with a dynamic infrastructure by:

    • Provisioning and setting up environments
    • Implementing dynamic scaling of compute resources
    • Migrating legacy workloads to the cloud
    • Deploy in multi-cloud and hybrid-cloud environments
    • Support heterogeneous environments

    harvey2.png

    Several speakers of All Day DevOps talked about automation, and all of them said a critical step is to treat infrastructure as code. According to Nathen, this means that to programmatically provision and configure components, such as servers, databases, firewalls, etc., you also have to treat it like any other code base. This includes version control and automated testing, but also:

    • Automated, full-stack application policies
    • Package and service installation
    • Versionable, testable and repeatable workflow
    • Scalable application policies
    • Management of interdependencies across nodes

    When you treat your infrastructure as code and deliver at scale, you can scale elegantly from one to tens of thousands of managed nodes across multiple complex environments.

    For software to be effective, users have to trust that it will do what they expect it to do. This is true from handheld calculators to self-driving cars, and it is also true when we automate our development and operations. Nathen advocates that we have to build a pipeline to production that creates faith in us that our code is ready for production.  This pipeline must:

    1. Test the code/verify locally
    2. Verify in pipeline with automated testing
    3. Approve with another engineer (aka code review or Nathen’s “four eye rule”)
    4. Build an artifact
    5. Deploy into acceptance environment to automatically test the artifact
    6. Ask someone else, “Do we want to ship this?”
    7. Ship the code with a click of a button
    8. Union (bring together dependencies and run tests)
    9. Rehearsal
    10. Delivered (ship to customers)

    What does the future hold?

    Infrastructure automation is NOT enough. Why? Auditors show up to audit your infrastructure and applications. The problem is, they use different tools—Excel spreadsheets, notebooks, PDFs, etc. This makes it very difficult to audit. Nathen advocates managing compliance documents as code, too. When we translate compliance into code, it can be executed as part of the pipeline so we can test for compliance throughout the entire life cycle.

    Finally, Nathen stresses the need to have application automation, too. Modern applications look like infrastructure as code.

    harvey3.png

    Developers can make applications that operations can deliver and run in production. This makes it easier to consume, run, and keep applications healty. Operable applications need to be:

    • Isolated
    • Immutable
    • Configurable
    • Built on a common interface for monitoring health
    • Rebuildable from sources
    • Reside in common packaging
    • Maintain runtime independence

    As enterprises implement infrastructure, application, and compliance automation, it creates a freedom for people to focus, and people are the key.

    Nathen notes that, “DevOps is a cultural revolution and professional movement, focused on how we build and operate high velocity organizations, born from the experiences of its practitioners.” He underscores that people are the future of automation. Automation places the priority on people, which enables great companies and great products.

    harvey4.png

    You can watch Nathen’s entire talk online here, where you can dig deeper into this subject. If you missed any of the other 30-minute long presentations from All Day DevOps, they are easy to find and available free of charge here.  Finally, be sure to register you and the rest of your team for the 2017 All Day DevOps conference here.  This year’s event will offer 96 practitioner-led sessions (no vendor pitches allowed).  It’s all free and online on Oct. 24.

    — Derek E. Weeks

  • Adding Accountability with ‘You Build It, You Run It’

    Adding Accountability with ‘You Build It, You Run It’

    Let’s see if this scenario resonates with anyone: Your department, organization, company, etc. is beginning to embrace DevOps practices, which is, of course, an amazing step in the right direction! One of those key practices is the “You Build It, You Run It” (YBI/YRI) mantra that helps facilitate a higher level of quality and accountability. This common practice also solves the mentality of throwing your solution/code over the fence for some other team to fix.

    I’m a huge proponent of YBI/YRI. However, in the case of existing brownfield solutions, there are several things you need to consider when transforming into the YBI/YRI model, including:

    • What if you have an existing solution where the collective “Y(ou)” in ‘You Build It’ does not include any or many of the original team that built it? This would be anyone who was part of the end-to-end creation of the solution and was empowered to make decisions impacting the design, development and delivery of a solution. In this case, it becomes, “Someone else built this mess, now you run it,” [SEBTM/NURI] which not only makes for a horrible acronym but is also a very realistic scenario that requires special consideration we’ll discuss below.
    • What if you are still heavily siloed and have a squad spread across multiple organizations, each with different goals and objectives? If you are still running outside of a true squad model, it can be difficult to ensure everyone’s priorities and goals are aligned to produce quality solutions with the right functions customers want.
    • What if you have varying definitions of “You” within your organization? Often in the YBI/YRI model, the interpretation makes some roles or key decision makers exempt from the glory of pager duty or answering to an angry customer. This can be especially true when you’re still trying to get to a point of having fully cross-functional, empowered squads.

    I think it’s fair to say that most DevOps transformations don’t necessarily happen on greenfield solutions, which means, especially at the enterprise level, the reality can end up being a beast of a monolithic solution(s) built by others who may or may not still be around.

    How do you fix it? My suggestion is that every person who was empowered to make a decision that contributed to the “B” (Build), becomes a “Y”(You). Of course, this doesn’t work if “Y” is no longer with the group or company, in which case I think it becomes a different issue of ensuring the new “Y” is 100 percent empowered with the ability to make decisions that enables that team to successfully run it.

    One more complication that adds to the mix of a YBI/YRI strategy is putting that strategy in place without a solid foundation of agile practices. Ideally when you are adopting DevOps practices, you already have a solid agile foundation with empowered cross-functional squads; however, in practice we often see the agile foundation still being built and/or refined at the same time as incorporating DevOps practices. As a result, there still exists a lot of hand-offs while two transformations are trying to run in parallel. If you have hand-offs combined with team’s with separate business objectives, those blurry lines of accountability will become an issue sooner than later.

    During transformations, if you find yourself in that in-between state of not having fully empowered accountable teams and are working with solutions your team may not have actually built, below are a few suggestions to get through those initial challenges:

    1. Ensure you allow for enough time to address technical debt during your sprint planning. Continuing to add features and functions on a poorly designed and/or broken solution will only cause further issues and likely increase the level of frustration on the team.
    2. Ensure that EVERY person who contributes to key decisions on a solution is included in the pager rotation in some way. Until you are in a state of fully empowered cross-functional squads, it’s important to drive the importance of accountability. As an example, if you have an architect in one organization who is working with a development team in another organization, that architect needs to be included on the pager as well to be aware of any problems resulting from a key architecture decision.
    3. Get in the habit of operational retrospectives. Begin (or continue) the habit of operational retrospectives that bring together the end-to-end squad into a cross-functional review of the operational incidents, root cause assessment and stories/tasks that need to get added to the backlog and prioritized.

    Although the transition into YBI/YRI for brownfield solutions can be muddy, empathizing with the mountains of technical debt and fully empowering solution teams can go a long way in truly helping your team’s succeed through the beginning phases of your DevOps transformation.

    About the Author / Shelbee Smith-Eigenbrode

    Shelbee

    Shelbee Smith-Eigenbrode is a senior software engineer/IT architect at IBM and has been in IT for 19 years.  She has worked across varying roles spanning the software development life cycle. Her experience across functional roles as well as performing that work deeply inside traditional silos has contributed to her passion for embracing the DevOps culture and transforming the way teams are delivering technologies by adopting DevOps practices. She is a member of the IBM Academy of Technology committed to driving innovation and technical advancement.

  • 8 Reasons Why DevOps Needs Competent Writing Skills

    8 Reasons Why DevOps Needs Competent Writing Skills

    It’s a fact: DevOps practitioners need to have competent writing skills to help them in their career. It may seem a little antithetic—after all, software engineers and programmers are well-known to be the kind of people whose brains are wired toward math, not English. Written communication may not be an area of strength for people who spend their days looking at code; however, it could set someone on the path to success.

    Here are eight reasons that highlight exactly why DevOps practitioners should work on their writing skills to advance in your career.

    There Are Similarities Between Writing and Code

    This may not be immediately apparent, as most English students would pale at the thought of writing code and most computer science students would cringe at the thought of producing an essay. However, writing and coding are very similar in the sense that they both require a clear mind, have a set beginning, middle and end, and normally address a problem. Plus, as writing is essential in finding and landing a job, you can boost your skills by practicing writing for CVs, resumes or cover letters.

    Learn from Each Other

    Software engineering is becoming an increasingly collaborative area of study; however, for people to get involved with your project, they need to know what it is and understand it. Being able to write well helps people understand and follow simple instructions and communicate clearly on what they want to achieve or add to a project. If you’re unsure how to write a proposal, you can find great advice in the writing forums or from online editors and writers.

    Become a Proponent of Literate Programming

    Codes are fundamentally written for a computer; however, literate programming supporters state that it should be written for humans, too. The code can have a longer shelf life and be a lot clearer and high-functioning if the people who write it have the interests of a human at the other end in mind, and if the code has a purpose that can serve human needs.

    The Role of Writing is Increasing

    Programmers do have to work with others at times, and even programmers who work on individual projects have to communicate progress and setbacks to their employers, universities or the people who provide funding. If you want to be able to keep all of these people happy so you can carry on with your work, then you need to be able to write quality emails and progress reports. You can find plenty of email and written communications help by using online proofreading free tools on the web.

    Improve Your Professionalism and Reputation

    If you can sell and market yourself well, then you’ll be better-received within your own specific field and within the organization that you work for. Poor writing, littered with spelling and grammar mistakes that leads to miscommunications, just makes you look bad and can make people doubt your ability.

    Make Sure You’re In Line for Promotion

    Programming is a competitive field, even if many of the people who work in it work independently. This means you need to stand out from other programmers when you want the best projects to work on, and getting advice from a professionals is the best way to present your ideas and goals can go a long way.

    Show Your Authority

    A lot of people you work for will not understand code, so you’ll need to employ other means to convince them that you know what you’re talking about. This could include using sources and references to describe why you’ve taken certain courses of action.

    Develop Better Relationships

    It’s always good, and sometimes useful, to maintain good relationships with colleagues, so you can make sure you aren’t being too curt by checking your emails with word count tools, to make sure you’re engaging and approachable.

    Writing and DevOps may not seem to go together; however as the list above shows, they are actually compatible and both necessary for anyone to really succeed in the workplace.

    About the Author / Gloria Kopp

    Gloria Kopp is a digital marketer and an elearning consultant from Manville, Wyoming. She is a regular contributor to such websites as Engadget, Ukwritings and Huffington Post. Connect with her on LinkedIn.

     

  • Veracode Makes DevSecOps Transition Easier for Developers

    Veracode Makes DevSecOps Transition Easier for Developers

    Following the formal acquisition of Veracode by CA Technologies, a much bigger effort to make security a more integrated element of DevOps has kicked off in earnest.

    Veracode recently unfurled an update to its application security platform aimed specifically at developers that provides security findings as each application module is scanned. Tim Jarrett, senior director of enterprise security strategy for Veracode, says the idea is to provide developers with that information from static analysis delivered via the Veracode platform as early in the application development lifecycle process as possible.

    Other new capabilities include support for custom cleansing functions to automate remediating issues involving common known vulnerabilities and an auto-scan capability that gets implemented any time a file is saved.

    Also with this release, Veracode is adding support for the Perl programming language that is still widely used for building web applications.

    Jarrett notes that organizations these days are holding developers more accountable for security issues that are easier to fix during the application development process. Addressing those same issues after an application is deployed in production not only exposes organizations to security threats, but can be much more expensive to fix.

    The challenge is that most organizations have yet to solve the riddle for getting developers to address security issues earlier in the application development cycle. Jarrett says far too many developers are conditioned to view IT security has being someone else’s job inside the organization. Veracode is trying to make it simple to address security issues using tools that make the process as frictionless as, say, relying on a spell checker to publish a higher-quality document.

    Obviously, there will never be perfect security. But far too many of the issues that IT security teams regularly deal with relate to known exploits. At a time when cybercriminals are making use of a variety of automated tools to discover those exploits, most IT security teams are outgunned. Worse yet, many IT organizations can’t even find qualified cybersecurity professionals to hire in the first place.

    On the plus side, however, as DevOps processes mature, many developers are now assuming complete responsibility for the maintenance of the code they write, including all security issues. This not only leads to higher-quality applications, it also results in those developers being more vigilant when it comes to address security issues they would otherwise need to address themselves once an application is deployed in production. In some quarters, this earlier focus on security in the application development and deployment process is referred to as DevSecOps. As a discipline within most IT organizations, however, DevSecOps remains relatively nascent.

    Of course, regulatory bodies are increasingly treating organizations that fall prey to security attacks less like victims. Instead, they are holding them accountable for ignoring best security practices by assessing fines for losing control over sensitive data. As those fines increase the blame for incurring those fines eventually cascades back to the developer. Given that changing climate, it might not be too long before developers recognize that embracing DevSecOps is in their own best interests.

    — Mike Vizard

  • The Tester: Saving Your Soul in a DevOps World

    The Tester: Saving Your Soul in a DevOps World

    Software testers have seen their careers go through some ups and downs in recent years. In the days of Waterfall, the tester’s job was clearly defined. Like other functions of software development and delivery, testers lived in a neat and tidy universe, testing features and design, finding bugs, sending back feedback to developers for correction and eventually, passing off code to the production people to work their magic. Testers had discrete roles with strong value propositions in the software organization.

    Then, Agile came along and new teams were created, lumping together developers, QA and Ops people for the sake of better collaboration and efficiencies. This began to create some confusion regarding who was responsible for what, when.

    DevOps brought order to the process, adding automation to every step, speeding cycles and reducing bottlenecks in a highly standardized, streamlined approach. In the continuous delivery pipeline, each step of the process creates its own contract for software quality—and that’s good.

    Development teams still value high quality, which customers demand. Yet in some DevOps circles, there’s been talk that testers aren’t needed much anymore. They bring bottlenecks to the process, forcing developers to work outside of the DevOps toolsets for code management and testing to respond to a defect ticket posted by the tester in an issue tracking tool.

    Eliminating that layer of process helps developers be as efficient as possible using continuous integration (CI) tools, proponents say. As well, some developers are more than comfortable handling testing, using test-driven development (TDD) methodologies.

    On the other hand, there’s faulty thinking here. Testers, whether deploying manual or automated testing methods, provide a valuable second set of technical eyes. Testers have a solid take on the user experience perspective, not just the fact that the code executes correctly.

    This human behavior and design insight is critical to the ultimate success of a software application. Finally, not all developers want to spend time testing nor have the skills to do so outside of unit testing.

    Moving forward into this new age of DevOps, testers play a vital role. The distribution of the tester into each phase of development (rather than at the end) is necessary to maintain both high standards of delivery and to keep communications fluid between different parties.

    Here’s how testers can contribute to DevOps teams:

    Testers need to be included in the continuous integration process

    Developers might be automating their unit test coverage, but they don’t replace all the test activities a tester can bring to the table. There are still other types of functional and non-functional test activities that must occur to validate the health of the product. Instead of transferring more testing responsibilities to the already overworked developer, testers can integrate their processes and systems with those of developers.

    Although there are version control tools (GitHub) and feature tracking systems (JIRA) to help developers, testers are often disconnected from these central tools. To connect with developer tools, testers can start creating and versioning their test cases within those development platforms. By doing so, testers can radiate feedback to the development team on issues to fix quickly through source code check-ins and in a way that won’t disrupt the normal flow of work.

    If testers can learn to use the DevOps tools developers love, much of the conflict goes away.

    Testers should increase their adoption of test automation, no matter their skill level

    Testers can learn newer test automation driven frameworks, especially those that help with transitioning manual test cases into automated scripts that can be reused, such as Cucumber or Gauge.

    For example, Gauge allows testers to write test specifications in Markdown, which provides a simple transition to automate your favorite programming language. These newer tools help testers transition to test automation despite not having experience writing tests this way—a common issue for testers working in DevOps.

    A growing number of test case management providers are starting to integrate their test design and execution around these automation frameworks to make the manual to automation transition smoother.

    Although developers might have automated unit test coverage, they struggle with developing functional and user acceptance automated tests. Testers can provide value by suggesting to the development team which are the best areas for test automation based on common issues and their unique knowledge of the application.

    They also can recommend areas for exploratory or manual test execution, depending on application complexity. This is especially helpful when teams starting down the path of DevOps do not have a regression test suite built that can be triggered through CI.

    Testers should focus on quality over finding defects

    Developers often complain that when testers find defects, it slows down their development processes. On a fast-moving Agile or DevOps team, filing bugs in a defect or issue tracking system is a total waste of time and creates unnecessary clutter.  Developers want instant feedback on code that’s broken and the related feature, rather than seeing another defect ticket they must open and close upon fixing.

    Therefore, testers should be giving feedback directly to the features that are being developed within a branch of code. They can do this through adopting tools that facilitate “ChatOps,” such as HipChat and Slack, which can integrate with version control systems. Testers can also provide direct feedback through a commenting system on the feature itself.

    With the advent of Agile and DevOps, which emphasize speed and frequent releases, testing is more important than ever in software development. By making some slight modifications to how they work and the tools they use, experienced testers can add considerable value to these teams by providing another layer of quality checks and a holistic view of an application’s performance and usability.

    About the Author / Ryan Yackel

    Ryan Yackel is Director of Product Marketing at QASymphony. He is responsible for all marketing activities around product releases, including development of strategic messaging. Ryan also helps to train the Sales teams on key value propositions for new products and features, and he provides customer feedback to the product team for roadmap initiatives. He can be found online at Twitter and LinkedIn.

  • All Day DevOps: Exploring the New Ordinary

    All Day DevOps: Exploring the New Ordinary

    There you were. You heard about Docker, become mesmerized, floated into its new, special world … and then all chaos broke out. Things were not that easy and you scrambled for knowledge. Some folks saw the light and stepped forward, while others are still trying to figure the out the happy path home where containers will become part of their new ordinary.

    This is the true story of Daniël van Gils (@foldingbeauty), a developer at Cloud 66, and the 12 steps he laid out in his Docker journey. He shared this journey during his presentation at the recent All Day DevOps conference, and I’ll share a summary of his steps here. His journey will take you full-circle, from your “ordinary IT world” to the “very special container world” and back, to where the container world is the new ordinary.

    Containerization continues to be a hot topic in the software world, and one that is only going to grow and mature. As it matures, questions still abound:

    • How can you implement containerization into your organization?
    • Have you already started but run into roadblocks?
    • How can you be the hero of your organization’s journey?

    Daniël addressed this journey in his talk, “Docker Inside/Out,” at the recent All Day DevOps Conference.

    Daniël’s journey started in the Ordinary World (#1), the world you might be in now. You are at a conference, you read a book, you talk to some colleagues and you want to jump into containers. You receive the Call to Adventure (#2) … but you are human, you like the safe, you fear the unknown, so you want to Refuse the Call (#3).

    Thankfully, others—including Daniël—have taken the journey. They can take you under their wings, coddle you and then push you out of the nest. You Meet a Mentor (#4) and follow your heart. The heart is the good stuff—it is the core. Like most people probably would have, Daniël chose an artichoke to illustrate his point.

    The heart of the artichoke is the good stuff, but the outer leaves protect the heart and make up the whole artichoke. Each aspect of an organization has something that drives them—their heart:

    • Development – building elegantly performing code
    • Operations – stable, performing code
    • Business – delivering the right services to customers
    • Customers – consuming the service they want

    Your drive to satisfy the heart’s desire gives you the courage to Cross the Threshold (#5). You have a containerization machine, such as Docker. You put code in, creating nice little containers.

     

    Now that your infrastructure is set up, you test and know where your allies and enemies are (#6). The most important lesson here is that shortcuts are your enemy. Shortcuts are evil, promising a life of ease but delivering a life of pain.

    Daniël offers his Approach (#7) through the Docker journey to ensure you’re successful. You must KISSSSS:

    Keep It…

    • Slim – remove what you don’t need
    • Secure – ensure you have the latest updates; remove all secrets
    • Speedy – Follow best deployment practices and run performance tests
    • Stable – Use version numbers for your Docker files
    • Set – Immutable. Don’t put databases or complicated volumes into your containers. You can, but the the technology is still too new.

    The next steps in his journey cover Ordeals, Death and Rebirth (#8). Once you pass this point in the journey, you’ll understand what it takes to run Docker in production and have shown the proof of concepts. You’ll then reap the Rewards (#9) and have clear visibility to your Road Back (#10) to the new ordinary.

    For the successful heroes on this journey, now is your moment to shine.  The next steps: your Resurrection (#11) and to Return with Elixir (#12) where containers are now the new ordinary.

    If you want to learn more about Daniël’s Docker journey, be sure to watch his full All Day DevOps conference session (only 30 minutes). The other 56 presentations from the All Day DevOps Conference are available online, free-of-charge here.

    This blog series is reviewing sessions from the All Day DevOps conference from November, which hosted more than 13,500 registered attendees. Last week I discussed, “One Team, 5,000 Jobs: Life in the DevOps Jungle.” Next week, look for “Launching Products at Massive Scale: The DevOps Way” presented by Kishore Jalleda and Gopal Moore.

    — Derek E. Weeks

  • One Team, 5,000 Jobs: Life in the DevOps Jungle

    One Team, 5,000 Jobs: Life in the DevOps Jungle

    Damien has 5,000 jobs. While you might gasp at that workload, Damien is not stressing out. All 5,000 jobs are automated within his team’s Jenkins pipelines. How does he do it? Damien follows four key principles to keep his cool in the job jungle: self-service, security, simplicity and extensibility. But you might be surprised that one of his most important survival techniques is treating his pipeline as “not code.”

    At the recent All Day DevOps Conference, Damien Coraboeuf (@DamienCoraboeuf, nemerosa.com) discussed how his organization got out of the job jungle. Even with 5,000 jobs in Jenkins, Damien has a tiny team of six running it while supporting a large band of developers around the world.

    During his session, Damien laid out how a pipeline, the backbone of a Jenkins job, is constructed. Spoiler alert: It is pretty simple; hence, the magic of Jenkins. However, it gets complicated quickly, so Damien shared four principles his team strives toward:

    • Self-service. They don’t want the Jenkins team to be a bottleneck, and they don’t want to have to deploy an army just to run Jenkins.
    • Security. With teams of developers—many of whom they have never met—security and control is critical.
    • Simplicity. Developers can focus on developing rather than Jenkins.
    • Extensibility. As they grow and capabilities are dreamed up or implemented, their system needs to be able to adapt.

    Core to their implementation and their goals of self-service, simplicity and extensibility is the Job DSL Plugin. While Jenkins has a robust user experience, as jobs are added, it can get cumbersome and clumsy. The Job DSL Plugin brings order, automation and consistency to the jobs. Damien walks through the basics of the plugin and its benefits, noting that it treats the pipeline as code.

    Treating the pipeline as code allows the team to reuse code through versioned libraries and easily manage thousands of jobs. Requiring developers to manage more work as code does offer benefits, but giving that many people access to the code also produces security risks. So, Damien’s team actually treats the pipeline as “not code” by describing the pipeline using properties files. It also allows them to use the pipeline as metadata, so queries and reports are almost enjoyable.

     

    Damien’s team also utilizes the Seed plugin, which they maintain, to “help automate the generation and management of pipelines,” tighten security by keeping projects locked to teams and increase automation through hooks.

    The Seed plugin shares some functionality with the popular Pipeline plugin, which is maintained by a large community. However, the Pipeline plugin does not allow for treating the pipeline as “not code.” Damien’s vision is that one day Seed will be an extension of Pipeline.

     

    Damien’s team has done a tremendous job of running Jenkins across the enterprise. In fact, he just wrote me with an update that since November, his company has scaled to 7,000 jobs while still following the same principles.  If you want to learn more about how his team does it, be sure to watch his full All Day DevOps conference session (only 30 minutes). The other 56 presentations from the All Day DevOps Conference are available online, free of charge, here.

    — Derek E. Weeks

  • DevOps: Making the Boring Things Stay Boring

    DevOps: Making the Boring Things Stay Boring

    “I, For One, Welcome Our New Robot Overlords,” is the title of Mykel Alvis’ (@mykelalvis) session at the 2016 All Day DevOps Conference. He wasn’t trying to curry favor with the new robot rulers, a lá Kent Brockman, but, instead, was evangelizing on the importance of precision in DevOps.

    Mykel is the DevOps Coach at Cotiviti Labs, the development arm of Cotiviti. Every day it handles healthcare data, which as you know happens to be some of the most regulated and protected data around. As Mykel said, “We don’t do cat pictures on the internet.” A mistake, breach, security flaw, etc., could mean the exposure of privacy and financial data for millions of people. But, it is a large organization, with exposure that needs to be managed. It has 200-plus repositories, three to four deployments per day, 15 developers and 0 operators (sort of). Without the right discipline and rigor, costly mistakes could happen.

    Hence, Mykel’s need for the robot overlords. As he noted during the conference session, robots have, “Lower utility, but greater predictability.” They do exactly what they are told, and they do it the same way, every time. By contrast, humans are superior to responding to unpredictable events. Mykel’s goal is to leverage the strengths of each. Cotiviti Labs has systems, policies, procedures and a culture in place that supports the automation of tasks as much as possible to ensure mistakes are kept to a minimum and the humans can focus on the unpredictable. The company is striving to make the boring things stay boring. Cotiviti calls it “The Labs Way” and here is how it does it:

    • Treat everything as code. Everything. Infrastructure, data, everything. As an example, it performs pull requests to get status updates for executive reports.
    • Test the code. 
    • Perform formal releases. Cotiviti builds its code in very specific ways, with extremely rigid gatekeeping processes.
    • Releases produce immutable artifacts. Once something has been released, it will never change it. It could, but it doesn’t.
    • Keep everything. Not in a huge, unorganized file system. In an organized repository.
    • Failing tests mean a failed build.
    • Design your systems to be automated. Cotiviti doesn’t do things that can’t be done automatically.
    • Deal with those systems only through automation. This is probably the most challenging thing it does since it is extremely hard to convince developers to write their code to do this.
    • Operations IS developing. Operations is not a bucket for development. Operations is a development task. You treat it like it is real code.
    • Because everything is code. Everything.
    • All defects are defects of code.

     

    To achieve this, Cotiviti:

    1. Standardizes
    2. Evaluates
    3. Tests
    4. Discards the useless
    5. Owns it

    None of this comes easy. It challenges norms. It pushes boundaries. It mandates discipline. (Pull quote – “Discipline is the bridge between goals and accomplishment.” – Jim Rohn) Your team has to understand you have a way to do things, there is a reason, and it will reduce risks and make sure everything works. It will keep the boring, boring.

    You can watch Mykel’s full presentation from the All Day DevOps conference here (30 minutes).  The other 56 presentations from the All Day DevOps Conference are available online, free-of-charge here.

    Want more to read? This is blog series is reviewing sessions from the All Day DevOps conference from November which hosted over 13,500 registered attendees. Last week I discussed, “DevOps for Small Organizations: Lessons from Ed”. Next week, look for “Getting out of the Job Jungle with Jenkins,” a discussion by Damien Coraboeuf.

    — Derek E. Weeks

  • How Open Source Can Help Your CD Chain

    How Open Source Can Help Your CD Chain

    What can you do to make continuous delivery work better? Consider moving to open source software solutions. Here’s why.

    Many DevOps teams already may be using open-source platforms for reasons not related to continuous delivery. They might like the cost-efficiency or interoperability that usually come with open source. Or maybe they just like the open-source philosophy.

    Typically, however, open source is not viewed as a requirement for doing DevOps or achieving continuous delivery.

    How Open Source Speeds Continuous Delivery

    But maybe it should be. Consider the following ways in which open-source code can better facilitate a continuous delivery pipeline:

    • It’s easy to tweak. Because anyone can view and modify the source code of an open-source program, you can change it to work as efficiently as possible. Custom enhancements could make the open-source tools you use work more efficiently within your delivery chain.
    • No vendor lock-in. Most open-source tools and platforms are designed based on open standards. The threat of vendor lock-in is minimal. For that reason, adopting open source helps prevent surprises that could otherwise hold up your continuous delivery pipeline in the event that a vendor decided to stop supporting the tools you are using.
    • It’s well-known. Mainstream open-source tools are widely used. Chances are good that the people who are currently on your team, or will join it in the future, already know open-source tools. That’s an advantage for continuous delivery because it means you won’t have to spend time training staff—and risk introducing delays to your continuous delivery chain while the staff are being brought up to speed.
    • It gives you options. With open source, you usually have lots of implementation options. Want to deploy on Linux? There are about a dozen mainstream distributions you can choose. Want to run your cloud with OpenStack? There are lots of distributions of that, too. Having choice is a good thing for continuous delivery because it allows you to switch easily between different frameworks or tool implementations as your needs change. That agility prevents you from being locked into a specific solution.

    This is not to say that open source is a silver bullet. Achieving continuous delivery requires attention a lot of other factors; it’s not as simple as using a certain type of technology (if it were, everyone would be delivering continuously). But adopting open-source solutions when possible certainly can’t hurt—and it just might help as you seek to deliver software continuously.

    — Chris Tozzi