devopsy.kinsta.cloud

Author: contributor

  • Automation: Achieving Faster Rollouts with Better Accuracy

    Automation: Achieving Faster Rollouts with Better Accuracy

    A changing landscape requires new processes

    At the recent Symposium/ITxpo, Gartner shared a list of technologies and trends that will be important for organizations to embrace and prepare for in 2017. These trends, which are listed in the report, “Top Strategic Predictions for 2017 and Beyond: Surviving the Storm Winds of Digital Disruption,” reinforce the breadth of technology that IT must support, roll out and engage with. This includes everything from the 100 million consumers who will shop using augmented reality to dealing with the roughly 21 billion endpoints expected to be in use in 2020.

    The report also demonstrates how fast technology changes directions. For example, Gartner predicts that in 2019, 20 percent of brands are expected to abandon their mobile apps. “Many brands are finding that the level of adoption, customer engagement and return on investment (ROI) delivered by their mobile applications are significantly less than the expectations that underpinned their app investment,” the report notes. However, this doesn’t mean less work. IT departments continuously have shift gears to support new processes, news apps and new technologies, such as the Internet of Things (IoT) and the massive amount of data that it produces.

    The dynamic needs of today’s businesses are driving organizations to increasingly adopt new technologies and applications that oftentimes don’t play nice with the existing set of infrastructure and legacy systems in place. So, while it’s clear that the technology landscape is changing, what isn’t so obvious is how IT and business decision makers should be adapting to an industry that is in constant motion.

    In-Steps DevOps

    To keep up, IT must implement agile methodologies that can adapt quickly to market changes. The DevOps mentality is making its way into many organizations and involves the development team creating, building and evolving products to ensure the organization is up to date, while the operations team confirms everything is running smoothly prior to a launch going live. This level of checks and balances isn’t just a nice to have, it’s a necessity—one mistake and the entire system can be brought down. Fostering a greater level of collaboration between development and operations makes it possible to efficiently and effectively build, test and correct new features and new products.

    While the shift to a more collaborative environment between the Dev and Ops teams can take time, using modern IT automation solutions can make this transition easier. Such solutions automate many of the routine—and even not so routine—elements of the application release process within DevOps. Many of the actions necessary to move from code to production—not to mention maintenance, testing and cleanup tasks—can be taken off the backs of developers and operations, saving them time so they can focus on higher-level projects and reduce manual errors.

    Finding the Balance Between Speed and Accuracy

    In 2012, Facebook announced it was increasing the speed at which it released code to twice a day, every day. As Chuck Rossi, director of Release Engineering at Facebook said, his team follows the advice “ship early and ship often.” Facebook continues to follow this model, and while the company certainly didn’t invent it, the model has caught on and is spreading among companies developing virtually every type of technology. The catch? It’s an incredibly time-intensive process and not every company has the resources necessary for a dedicated release team. Plus, a true shift to DevOps doesn’t happen overnight, especially since there is a ramp-up time for folks to get on board. For example, Phil Dibowitz, systems engineer at Facebook, told TechTarget that it “led its Chef team through a three-year process to rethink configuration management to scale on par with the web-scale company’s data centers.”  This took three years, he said, “not because of the technological change, but because of the structural change.”

    A slow transition to a new technology or new way of operating is a common occurrence because historically the production systems are cordoned off from development groups. While the Ops team has to ensure the rollout will meet certain standards, the Dev team wants to speed the process to begin the final rollout process as soon as possible. A happy medium exists, but if it isn’t found, things can go very wrong. Unfortunately, 2015 gave us two major examples of what can go wrong if products can’t speak to each other and rollouts are completed too early: Remember the New York Stock Exchange and United debacles?

    Breaking Constraints Through Automation

    This is where modern workload automation comes into play. Automation and solid change management allows IT to flexibly add on new technologies with automated processes for building, testing, upgrading and configuring IT—all while reducing the slack time between various steps. For instance, a workload automation solution should be able to trigger a build, deploy the build to the test environment, run the test suite and, assuming testing meets acceptable criteria, promote the build to production. If something does go wrong, necessary remediation can occur, and through monitoring and alerting capabilities, the required parties can be notified proactively.

    Additionally, automation solutions with pre-built integrations make it easier for disparate applications to communicate, creating an end-to-end approach to workflow creation and maintenance. As a result, IT organizations can minimize the risk of business disruptions and achieve a more fluid technology delivery to the business.

    Although it’s not a silver bullet that will solve all DevOps transition issues, automation does reduce manual intervention, which leads to fewer delays and errors and improves speed at which tasks are completed. However, beyond the technological aspects, there must be a clear understanding by both sides (the Dev and Ops group) on what their counterparts need—and this requires a high level of trust and coordination.

    While the specifics around the DevOps methodology certainly will change, automation will remain a critical piece of the process. With IT automaton, DevOps teams are able to refocus on critical IT business and operational processes, thereby reducing delays, decreasing errors and improving the speed at which tasks are completed. Ultimately, automation makes it possible to increase the speed of product releases and enable companies to stay ahead in the age of unpredictable customer preferences and ever-changing technological developments.

    About the Author / Mehul Amin

    Mehul Amin, a 21-year veteran of Advanced Systems Concepts Inc. (ASCI), previously held roles as product engineer and technical support manager and played an integral part in building the company’s workload automation solution, ActiveBatch. In his current role as director of Engineering, Mehul drives high-profile initiatives and leads both the Product Engineering and Release Engineering teams. Mehul received a master’s in computer science from the Stevens Institute of Technology.

  • Time, Training: How to Implement DevOps Effectively

    Time, Training: How to Implement DevOps Effectively

    Successful implementation of DevOps solutions requires two very important investments: time and training.

    New technologies have always transformed how the commercial world operates. The steam engine for example, fueled the industrial revolution of the 18th century and changed the face of business forever. This dramatic shift didn’t happen overnight, though; people had to learn new skills to manage steam power and operate trains, ships and equipment that previously did not exist.

    Adopting a new system within a modern day organization is no less challenging. It takes in-house expertise and top-down leadership to crest the learning curve as quickly as possible.

    Training Your People

    To realize the benefits of DevOps, businesses need people—particularly, system administrators and their managers, who know how to operate the systems. It really is that simple, yet most companies just don’t have the skills. Training, training and more training, coupled with lots of hard work and practice, is paramount.

    Middle managers in charge of integrating the new systems are first in line for training. They deal directly with upper management as well as with the new software’s end users. To communicate the importance of DevOps to both audiences successfully, they need to understand exactly what DevOps can achieve—and how to get it up and running in line with the company’s wider business goals. They need to know what skills are needed to implement DevOps companywide and identify the right people to learn the ropes quickly and efficiently.

    Push from the Top

    A successful switch to DevOps also is dependent on support and buy-in from upper management. They don’t necessarily need to have an in-depth knowledge of the systems, but they do need to push for fast and effective implementation—and allocate the resources to make it happen. With all key stakeholders working together to reach the same realistic timelines and deadlines, the new systems will be introduced far more seamlessly. If the process is at all disruptive, people will be reluctant to change their way of working and do things the same way they always have.

    Senior management must support the system change and encourage its use across the organization by openly embracing its potential.

    Test the System

    Traditionally, implementing a new production system was a long, onerous process with lots of restrictions and administrative hurdles to jump. In many instances, a committee of key stakeholders was needed to verify and approve each step. Forms had to be filled out, a thorough backup plan would be prepared and a bureaucratic chain of command would be followed. The further removed from the actual implementation project each signatory was, the less committed they were—which often led to repetitive meetings and costly delays.

    This labor-intensive change management approval process was in place to help prevent any failing in the production plan, which could have disastrous effects. Should for example, an online retailer’s check-out or internet banking infrastructure go down, business profits and reputation would suffer significantly.

    Implementing DevOps is different. It uses a test environment to speed up the onboarding process and minimize errors. IT engineers can do dry-runs before going live to check how the new systems are integrating and if anything is wrong before it actually does go wrong. Bugs and glitches are fixed without impacting the current systems and the approval process is far faster and much more confident. All of which can speed the entire implementation process and its success.

    The potential of DevOps is inextricably linked to the people who implement and operate the new systems as well as the old. To achieve the best possible outcome, your team needs to have the experience and skills to ensure a seamless integration that enhances core business functions without losing or disrupting the organization as a whole.

    About the Author / Francis Miers

    Francis Miers is a Director at Automation Consultants – Automation Consultants (AC) is an IT services and software company with a mission to improve the speed and reduce the cost of IT project deployment by implementing automation across the software life cycle. AC develops and deploys advanced software automation solutions. Customers include BskyB, HSBC, Invensys, Orange, EverythingEverwhere and Vodafone.

     

  • DevOps Leaders Share 2017 Reflections, Predictions

    DevOps Leaders Share 2017 Reflections, Predictions

    As the New Year kicks off, it is a time for reflection and a chance to look ahead and plan for what is to come. While many are making personal resolutions pertaining to their physique, job performance or travel plans, there is a lot of chatter in the software delivery space around what DevOps will look like these next 12 months.

    Looking back on 2016, suffice to say it was a big year for DevOps. There was no lack of resources for those in any phase of a transformation, with global conferences touting its name to weekly (if not daily) podcasts and webinars designed to share the latest expertise with the community. However, as DevOps moves from buzzword to phenomenon, it will be held to even higher standards and scrutiny, becoming ever-more polished and perfected as challenges are faced and overcome. But don’t just take my word for it.

    Electric Cloud recently hosted a live, online video podcast featuring notable DevOps luminaries discussing their own reflections and conjectures. The panel included Nicole Forsgren, CEO and chief scientist at DORA; Robert Stroud, principal analyst at Forrester; Chris Riley, analyst at fixate.io; Manuel Pais, author at InfoQ and SkeltonThatcher; Alan Shimel, editor in chief at devopsy.kinsta.cloud; Sam Fell, VP of Marketing at Electric Cloud; and yours truly. This article highlights 16 different insights from our discussion with these great minds in DevOps. Here’s to what has been, and what is to come!

    • Expect to see a trend toward strategic DevOps transformations in 2017, according to Forsgren: “I think there’s going to be a huge trend moving forward to do really careful and strategic assessments about where you are, intentional prioritization and strategy about understanding what your constraints are, so that you can do strategic capabilities development moving forward.”
    • Riley hopes 2017 will be the year we stop talking about DevOps and start doing it: “In 2017, we’re going to stop defining DevOps, and we’re going to hopefully use the word a lot less. We’re going to be real about what it is and getting it done. It’s going to be a lot less talk and more doing.”
    • I emphasized that having good architecture in place is crucial to successful DevOps: “What’s starting to happen is that you’re going to have a really hard time doing DevOps well with a crappy architecture, whether that be a crappy architecture for your pipeline or crappy architecture for your application. Application architecture matters in your ability to do DevOps well.”
    • Stroud emphasizes the importance of experimentation in DevOps: “Organizations [will] look to drive mainframe R&D in a DevOps methodology—not just mainframe development, but also supporting velocity in rolling it out to production, with organizations moving from one or two major releases a year, to now experimenting with both quarterly and monthly releases using DevOps practices and experimentation and techniques.”
    • While tools and processes play a major role in a DevOps transformation, we must not forget to maintain a culture of empathy, emphasizes Shimel: “Have empathy for your fellow workers, empathy for your fellow humans. Don’t think because you’re the dev, that what you’re doing is more important than what the ops guy is doing.”
    • DevOps certifications are the future, according to Pais: “I think we’re seeing more and more DevOps education and certifications. I know, for example, there’s an IEEE standard for DevOps being worked on.”
    • Sweat the small stuff, advises Fell: “It’s never been truer than in this accelerated cycle that we’re seeing with productivity and all this awesome value being created from relatively minor, incremental improvements in process, in tooling, and all the stuff that we do, and the feedback that we’re getting.”
    • I believe 2017 will bring major disruption in the FinServ community: “We will see some, hopefully, interesting disruption in the financial technology area, because the financial institutions have always treated technology as a key differentiator. Now, the problem they have is that their culture, by and large, sucks.”
    • Some wise words from Stroud: “Strategy without execution is wasted time. We have to execute. We have to be prepared to fail. We have to be prepared to come and share our experiences.”
    • Measure, measure, measure is Forsgren’s DevOps focus in 2017: “What’s going to be my goal is having all of us think about measuring in smart ways, so that we can actually do these experiments that are small, that allow us to fail, because big massive failures are scary, but those are the ones that are easy to measure with crap measurements. Because when you fail big, you know you failed big.”
    • In 2017, we will see a breakdown of DevOps tools’ silos, per Shimel: “It’s really ironic that in something like DevOps, where the idea was to break down silos between dev and ops, dev and QA, and QA and security, but what we’ve done is we’ve built new silos of DevOps tools.”
    • Pais on the trends he sees in early adopters of DevOps: “For the majority of organizations that have already been doing DevOps for a while, they’re now focusing on what’s the best way to organize teams. Moving, often, from having just specific people who know about continuous delivery, DevOps and so on, to actually getting platform teams that embed all the services that they want the development teams to use.”
    • Oddly enough, development teams are still more likely to adopt DevOps than operations teams, explains Stroud: “One of the data stats we pulled has to do with DevOps adoption in development versus operations. Isn’t that ironic? Because the name DevOps is dev and ops. We still see significantly more DevOps adoption in development than operations, but the good news is the gap is closing, based on the Forrester data.”
    • Containers will continue to be a major player in 2017, says Riley: “Where I believe there will continue to be growth is container-native tooling, container-native security and container-native release automation.”
    • The reality is, there are still a lot of organizations not doing DevOps, remarks Fell: “We are living in this bubble, happy bubble, of everybody gets DevOps and we’re all Agile. But we talk with folks that we talk to who are just like, ‘Yeah, we do nightly builds, and we’re really looking forward to doing continuous integration.’ Your jaw drops, like, ‘Wow. Yeah, that’s a good idea. You should do that.’”
    • And, finally, I share some sage wisdom to keep in the back of our minds: “If what you’re doing on any given day isn’t moving that ball forward, what is the point? I think we need to focus a little more on that.”

    Bonus 17th quote for 2017, from Shimel: “I think the story of 2016 is DevOps has gone mainstream. We’re seeing pockets of DevOps come together as bubbles, but we still have the majorities in front of us, going forward.”

    For more reflections and predictions, watch the full episode:

     

    About the Author/Anders Wallgren

    leadership-anders-wallgrenAnders Wallgren is Chief Technology Officer of Electric Cloud. Anders brings with him more than 15 years of in-depth experience designing and building commercial software. Prior to joining Electric Cloud, Anders held executive positions at Aceva, Archistra, and Impresse. Anders also held management positions at Macromedia (MACR), Common Ground Software and Verity (VRTY), where he played critical technical leadership roles in delivering award winning technologies such as Macromedia’s Director 7 and various Shockwave products.  Anders holds a B.SC from MIT.  Connect with Anders on LinkedIn or Twitter.

  • DevOps in 2017: From Building to Executing

    DevOps in 2017: From Building to Executing

    In 2016, DevOps grew in popularity and use, new tools were introduced and enterprises across industries realized the influence and benefits derived from agile development. But there are even more developments to look forward to as enterprises engage DevOps teams further.

    Scaling-out solutions, providing a baseline for a new cultural approach to problems and continuous improvement will continue to be priorities. But there are a few items that we’ll likely see come to the forefront in the new year. In fact, 2017 should be an even more exciting year for DevOps.

    Here are my top four predictions for what we can expect this year:

    The next phase of DevOps will focus on security

    Security was a perennial news event throughout 2016, and we can expect the same in 2017. However, DevOps teams likely will be challenged to build good security practices into code as a part of application development, rather than refining security post-facto. This will lead to DevOps, QA and operations bringing security teams deeper into the DevOps environment, if not outright incorporating them as a part of the team.

    The foundations for this development were put in place in early 2016 as the DevSecOps model gained traction in cybersecurity circles throughout the year. In 2017, we’ll see DevSecOps teams build on these foundations. After all, every company is at risk for a data breach.

    Containerization will go mainstream

    The convenience of containerization makes it one of the most desirable technologies for DevOps teams, and next year we’ll see it gain even greater use. It’s easy to understand why: Containerization solutions, such as Docker, grant teams the ability to provide a consistent environment from development to production. We may even see containerization move to non-production environments over the course of 2017 due to its portability across multicloud platforms. And that portability is critical not just for production purposes but for security as well.

    DevOps will extend into pay-as-you-go

    DevOps will, almost by necessity, develop an on-demand model in 2017. Companies are realizing the stark demand for DevOps skills and they will be meted out according to internal needs and external demands.

    In particular, we’ll likely see a lot of opportunity for DevOps in cloud implementation, since enterprises leverage solutions across cloud providers. With cloud provider “lock-in” still a real concern for many enterprises, any provider capable of operating cross-cloud development—thereby allowing customers to switch to a low-cost cloud provider—will be in high demand. This is good news for customers, as it allows them to finally benefit from the elastic nature of cloud pricing models.

    DevOps will become pervasive across the enterprise

    Finally, enterprises will use DevOps across the enterprise. Thus far, large enterprises have been experimenting with DevOps in discreet projects, but they have started to plan for employing DevOps principles at enterprise-level, and we will see this roll out next year.

    Watching the Shift

    Thus far, DevOps has been focused on adopting and orchestrating technology and tools to build automation pipelines. But moving ahead, we’ll witness DevOps change its focus from building to executing. With this industry development and the shift within DevOps to security and containerization at an enterprise level, we’ll begin the true potential of DevOps.

    About the Author / Tan Moorthy

    Tan Moorthy is Head of Global Services for Application Development and Management at Infosys, a next-generation IT services provider. Connect with him on LinkedIn.

     

  • The Code Doesn’t Lie, and Other Operations Mantras

    The Code Doesn’t Lie, and Other Operations Mantras

    As engineers, we spend a lot of time talking about things such as release processes, QA environments and deployments. But at the end of the day, most software systems fail because the software itself is faulty. The code doesn’t lie—you can almost always find the solution to your problem within the code itself. Of course, looking to the code for answers is a time-consuming process if you’ve deployed too much in one batch. After all, sometimes the tiniest mistake can derail a whole string of code, and having to sort through a haystack of code looking for a tiny needle is not fun.

    There are a few corollaries to this mantra that “the code doesn’t lie”:

    • “Know your data like you know yourself.” Sometimes the quality of the data itself can cause a system to behave differently.
    • “A feature is a bug in a tuxedo,” which is largely for you product folks out there.
    • “Where there is one bug, there are many.” When you find a problem and it leads to a systemic set of problems, it may seem terrible at first, but the reality is, you have the opportunity to fix a lot in a short amount of time.

    I had a chemistry teacher who used to say, “A mole is a mole is a mole,” referring to Avogadro’s number. My version is: “A bug is a bug is a bug.” A feature that behaves incorrectly (even if built to spec) is a bug. A badly performing system is a bug. A transient failure is a bug. A race condition is a bug. No matter what they look like, it’s our job to squash the bugs.

    Branch Readiness is a Joke

    A very talented engineering director once made the comment, “Branch readiness is a joke,” about the branch/development model. As 23 different teams were preparing their branches for integration onto the main trunk, code changes were flying around with very little testing/certification. We even had code that would not compile.

    When all 23 branches hit the main release branch, all hell broke loose. And this is where the actual functional, integration and performance testing began. The key problem with this model is that integration and certification happened late in the game. The other problem was that we did not abide by our own criteria of what constituted branch readiness; instead, we were constantly softening the restrictions until bad code made its way into the system.

    We moved to a trunk-based model of development where check-ins are made directly to the trunk, and all code must compile and be pretested. Continuous integration and testing are run against the trunk all day and all night. We can ship from the trunk at any moment.

    Now you may be asking yourself, What does this have to do with operations? The answer is: everything. We can control what changes get to the site. We can certify what changes get to the site. We are assured at every moment of a minimum quality in the changes that do get to the site. These smaller changes give us the ability to move bits onto the site more frequently. We are not forced into large-scale, monolithic deployments, which inherently create more risk to the site itself, often with little ability to roll back.

    Learning from ‘Branch Readiness is a Joke’

    Just because the code doesn’t lie does not mean that you can always understand all of its implications. The key is limiting the amount of code being changed in any individual release to an amount an engineer or automated system can understand. By avoiding large, monolithic releases containing thousands of changes and instead testing, verifying and considering each change individually, we can understand what the code is telling us. We can release to the trunk with confidence that what we build and deploy is going to work.

    The One-Character Change

    We live in a world of bits and bytes (eight bits per byte). One byte is the equivalent of one character. In some cases, a one-character change is benign. For example, changing the number of members of a site on an informational page from 134M to 135M (4 to 5) will not cause any harm to the site.

    But sometimes, a one-character change can be disastrous. Consider a DNS change that has a one-character mistake for www.yourcompany.com. Get it wrong and you are off the air. It is very important to understand the impact of a change going awry. If it can cause a large impact, then we need to ensure we understand the change and have a clear plan to roll it back if we need to.

    Here’s a great example of a very small change going sideways very fast: We once scheduled a maintenance to test routing traffic through a European point-of-presence. Unfortunately, the time-to-live parameter was set to a large number (hours instead of minutes) on the DNS entry. The result was that the change, once implemented, couldn’t be fully undone for hours. It was a one-character change with a bad outcome.

    Learning from the One-Character Change

    The code doesn’t lie, but that only matters if we are paying attention. Put simply, not all changes are equal. By taking the time to think about what a change is intended to accomplish and the various ways it could go wrong, we will always be better off than if we didn’t do due diligence. The one-character change can be benign, or it can be catastrophic. It’s important to figure out the possible ramifications of any changes (no matter how small they may seem) before proceeding.

    Operations tends to be the first group to get called after hours when something goes wrong. As a result, we have a vested interest in quality of code shipping to our site. By working to improve the code quality before it hits production, you can significantly reduce the number of problems you encounter.

    Start with where the code gets committed into source control. For each change made ask the simple questions: Does the code still compile? Does your application still build correctly? Does it still work as intended? By automating the process of asking these questions for every change, we gain the ability to deploy new versions of our application based on any commit.

    Once we have good code quality making it into source control, we can begin making further improvements through the use of a canary process and start focusing on things such as performance. Remember, the code doesn’t lie. If we can understand each change, then we can start preventing problems before they begin.

    This post is part of the series “Every Day Is Monday in Operations.” Throughout this series we discuss our challenges, share our war stories and walk through the learning we’ve gained as Operations leaders. You can read the introduction and find links to the rest of the series here.

    About the Author / David Henke

    David Henke has more than 35 years of experience working in technology, including senior engineering leadership positions at LinkedIn, Yahoo!, and AltaVista Company. He’s also been a founder at two different software companies, both of which were acquired. Currently, David serves in a variety of board and advisory positions with organizations like NerdWallet and UC Santa Barbara.

  • Best DevOps Practices for 2017

    Best DevOps Practices for 2017

    Because the idea of DevOps is still so new, we’re continually having to hone what we view as best practices. At the start of the new year, many people make their own personal goals clear for the year (regardless of whether they intend to keep them), but we tend to head back to our work desks without reassessing how our projects are going. We just jump back in unquestioningly and continue down the path we were on before the holiday.

    Mindless plodding away at a goal that had been set too far in the past is perhaps the biggest business mistake we can make. Re-evaluating our approach is often the difference between stagnation and real innovation. A willingness to change tacks and the agility to do so speaks volumes about an organization—that flexibility is rewarded by a market that demands responsiveness from its providers, and it can be a big differentiator between a company and its competition. With that in mind, there are six big goals that we can adopt as DevOps practitioners that will have enormous results on our ability to answer the demands of our users.

    Make paying off debt a priority

    Most companies are so saddled with technical debt that they hire more people just to cope with it. This is like putting more hoses on a forest fire. When fighting a forest fire, a portion of the team creates a firebreak to deprive the fire of fuel. Likewise, organizations need to dedicate a portion of their workforce to do nothing but eliminate the technical debt that is fueling their operational fires.

    Set ambitious goals, but don’t sweat the details

    Have goals and objectives, but allow the minutiae to be developed over the course of short intervals. We need to set business-level objectives for our DevOps teams, but we have to be careful to not overprescribe the details. There are many DevOps tools and methods and more arrive every day. Plan to work in two- to four-week sprints with measurable outcomes, instead of six-month project plans. Use the feedback and lessons learned from those short sprints to inform the next sprint’s work.

    Don’t leap, but get moving

    DevOps is meant to be about quickly moving product from left to right. A common mistake is for companies to wait for “the perfect moment” and then jump headlong into DevOps, creating a lot of disruption at once. This is a recipe for disaster. Identify workstreams that are ripe for improvement from DevOps and start by moving one new benefit from concept to production. Remember, single-piece flow is your friend.

    Identify the ‘credit hawks’ and neutralize them

    I once heard the saying, “Just because you run out in front of a parade doesn’t mean they are actually following you.” One of the critical pieces that makes DevOps work is a culture of sharing. That means sharing in knowledge, work, credit and blame. A “credit hawk” is someone who likes to jump in front of work already being done and claim he or she is orchestrating it. This seems to be commonplace in situations where DevOps teams exist under mid-to-upper managers with “old guard” mentality. If they take the credit, that leaves the DevOps team with the blame. Neutralize the credit hawks at all cost; they will undermine your culture.

    Plan for failure, success through learning

    Planning for failure does not equate to “expect failure,” but because we want to move faster so we can try more things, the law of averages tell us that we will also fail more, too. Planning to fail means we know how to conduct a blameless post-mortem, understand lessons learned and incorporate that feedback cycle to increase the likelihood of success.

    Promise to break the rules

    Your DevOps team needs to be trusted to find the best path, even if that means ignoring a 70-year-old process. This statement might invoke a knee-jerk reaction, but this does not imply “anything goes.” Your objective is to find more productive ways to get product to market and to create safe systems of work. Part of your lease to your DevOps teams also should be to explore new processes that eliminate red tape, bureaucracy and waste. What has worked for the last 70 years may be what is holding you back today.

    2016 rewarded those who were able to move fast, and 2017 promises to require us to move even faster. By resolving to make these changes in your company or organization, you are making a commitment to shed the shackles of yesteryear. When freed of these fetters, your application teams will be able to focus and deliver on the one thing we are all trying to do: deliver value directly into the hands of our customers. Is 2017 the year your company will triple its release cadence? Is this the year you deliver every new product into all markets simultaneously? Or perhaps this is the year when your applications suffer zero outages. The goals and the stories are yours to tell, but one thing is for sure: Resolutions without action are just wishes.

    About the Author / Adam Bowen

    Adam Bowen is an information technology leader with more than 15 years of experience in technical, sales and senior leadership roles. As the Worldwide Innovation Lead at Delphix, Adam works with thought leaders of the Global Fortune 100 to eliminate key business constraints through innovative new  processes, offerings, and technologies. Connect with him on Twitter and LinkedIn.

  • Automic Helps DevOps Transformation Sparkle

    Automic Helps DevOps Transformation Sparkle

    Working closely with Automic, an international wholesaler and retailer of jewelery transformed a department of project managers, developers and operations responsible for all of the customer-facing websites into a DevOps organization. As a result, project delivery was completed with 90 percent fewer delays, and first customer-facing releases of projects could be delivered in less than half the time. The usability of its websites increased significantly, resulting in more customer traffic, longer average time spent on the sites and increased revenue.

    Haphazard Development

    Prior to the DevOps implementation, new projects were delivered by “waterfall” project management means. The cyclical resource planning process was based on the project portfolio and business priorities. Project managers then planned project milestones working closely with business stakeholders, business analysts and application developers. Analysts created specifications and developers were assigned to work on packages and tasks to implement them.

    Different web technologies were used with varying levels of dev and ops expertise in each technology. The  Operations team members usually fulfilled requests made during the course of a project as part of their overall daily tasks—for example, to provision a new environment, deploy a package or change the environment configuration.

    This approach had a major disadvantage. Delays in one project impacted the overall resource planning and could have a cascading effect on other projects. Delays in projects could be for multiple reasons, such as waiting for business stakeholder impact, frequently changing requirements, unexpected sick leaves of developers or poor estimates. Other frequent causes included delays in operations tasks such as a deployment or provisioning of a new environment. These delays were caused by unaligned planning as well as a mismatch in priorities between projects and operations. Besides delays, some developers were underutilized, which also was exacerbated because they were specialized in a technology or component.

    DevOps Transformation Solution

    Working closely with the customer, Automic restructured dev and ops by:

    1. Switching the development from a project to a product mode (cross-project development teams based on capabilities rather than assignment of individual developers to projects).
    2. Moving project managers from development micromanagement to focus on major milestones and deliverables to the business.
    3. Enabling some project managers as product owners (project management remained necessary).
    4. Providing developers with agile methodologies through initial training plus ongoing coaching (six to 12 months).
    5. Providing ops with an agile methodology.
    6. Organizing both dev and ops into multiskilled teams focused on individual products rather than technologies.
    7. Aligning ops into delivery teams, initially part-time and later full-time.
    8. Giving delivery teams the end-to-end responsibility for their products, including their operations.
    9. Standardizing the technology stacks within teams (but not across them) over time.
    10. Delivering projects into production (or alpha, beta) in slices (releases) instead of just once to get early feedback and improve.

    Results: Fewer Delays, Better Usability

    By standardizing, this customer has transformed its dev and ops teams, creating an agile, scalable environment that can drive the business forward. The company achieved the following specific results:

    • Project delivery are now completed with 90 percent fewer delays. First customer-facing releases of projects now are usually delivered in less than half time.
    • The usability of websites has increased significantly, resulting in more customer traffic, customers remaining longer on the sites and increased revenue opportunities.

    About the Author/Michael Schmidt

    Courtney-Glymph_avatar_1435225162-96x96Michael Schmidt heads DevOps Practice at Automic, a management and technology advisory service established to help Automic customers to prepare for and transform their organizations toward DevOps. Michael spent his carrier as consultant, entrepreneur and in several product-related leadership positions. He has a passion for building lean IT organizations. Michael holds a joint MBA from New York University, London School of Economics and HEC Paris and a Master of Computing Science.

  • Using Guilds to Combat Information Silos

    Using Guilds to Combat Information Silos

    At xMatters, our group of 100 or so talented engineers is subdivided into teams tackling everything from front-end work to release automation to user interface (UI) and user experience (UX). As is common in an agile-minded organization, our engineering team members are cross-functional, with knowledge and expertise that carries over into areas outside their main focus. The advantages of this cross-functionality are an enhanced, self-organized form of collaboration and a more contextual understanding of project needs and goals—all of which ultimately lead to faster innovation.

    When I joined the company seven years ago, we had three engineering teams. We were already utilizing agile methodologies to eliminate as many inefficiencies as possible and streamline the continuous delivery process. However, as we grew to six, seven and upwards of eight teams, we realized that agile principles weren’t enough to scale the benefits. There was still a tipping point at which critical information started to silo and communication hurdles began to creep up between teams.

    Despite the stellar performance and incredible strides we had achieved with our platform, there still was room for us to grow and become smarter, faster and more productive. We needed a solution for this problem at the team-level, and for this we found that another cultural transformation was necessary.

    Here’s how it started: We observed that many of our engineers had keen interests in areas outside their usual scope, and that we could harness their interests as a valuable resource. There was the possibility of another kind of team—less official and more fluid—that would allow us to capture new ideas and solutions to problems as well as give our engineers the opportunity to engage in their interests.

    Thus, we adopted the concept of “guilds,” originally pioneered by Spotify’s development team. While Spotify’s structure is more complex to account for its nearly 2,000 engineers (it utilizes squads, tribes, chapters and guilds), the premise is the same: Allow people from different teams to come together fluidly and collaborate on a shared purpose. Our teams already utilized Slack for internal communications, and so we also created relevant channels for guilds.

    For instance, the UX guild exists separately from our dedicated UX team to include members from the front-end and other teams. We also have a test guild, comprised mostly of QA team members, who meet in person or over videoconference on a monthly basis. Our architecture guild features people from across nearly every engineering team who are interested in discussing the way we build our platform and structure our code base. Whenever people have an architecture-related problem, they post it to the architecture guild, and its members devise, record and vet a solution.

    In one case, we needed a way to configure all our customer’s environments and also replicate those configurations globally across our data centers around the world. The conversation about this issue arose in the architecture guild channel, and through it we gathered all of the necessary information and expertise to work on a spike and write a complete architecture document.

    If you’re at an agile-minded organization and are thinking of implementing guilds, the most important thing is to create an open, welcoming environment. Don’t try to structure them or make them overly formal; in principle, they should be self-governing entities that are virtually hierarchy-less. One of the coolest things about guilds is that they will be self-vetted by your community of engineers, so as soon as one no longer serves a function or becomes redundant, it naturally will fizzle out. We saw this happen with an auto-testing guild (for automation testing vs. manual testing)—it was essentially absorbed into the testing guild.

    Remember, in addition to bringing together experts in different areas, you’re inviting newbies who are interested in learning. There are so many advantages to this approach: You not only benefit from free user testing—in the case of the UX guild—but you also can harness a diversity of skill sets and creative minds to solve problems. As Einstein once said, “We cannot solve our problems with the same thinking we used when we created them.” NASA has taken this idea to heart, and has long used public crowdsourcing to solve problems for humanity in space and create new, innovative projects.

    The people who ultimately create the solutions often don’t have any traditional experience or expertise in the same area as the problem itself. Sometimes, it takes the collaboration of those both near and far from an issue to overcome it.

    About the Author / Nick Fletcher

    Nick Fletcher, Engineering Manager at xMatters, started designing and developing websites back in 1998, when the World Wide Web was the Next Big Thing. In the time since that first website, he’s mastered all the aspects involved in creating great products: design, development and strong leadership. Connect with him on LinkedIn.

  • Breaking the Cycle of Dependency

    Breaking the Cycle of Dependency

    While technology is an important component of DevOps and accelerating delivery, there are other aspects of process and culture that are critical to keeping the cycle moving to realize the goals of reducing lead time to become more responsive to the needs of the business.

    If you go to most agile teams and ask the question of what is stopping them from going faster, they will typically respond that they are waiting for “something.”  Something can include:

    • Waiting for work to enter their backlog
    • Waiting for environments
    • Waiting for another development team to provide some service or capability that is needed

    These obstacles include:

    • Large batch sizes
    • Lack of continuous flow of work into Agile teams’ backlogs
    • Calendar-based gated releases
    • Test environment complexities
    • Environment availability

    This manifests itself in the current state as shown below as the vicious cycle. When teams are only delivering system releases a few times a year, then the business believes it needs to pack everything it can think of into that release, since waiting for the next release incurs a delay of months. The leads to large complex releases with many dependencies. This, in turn, slows down the development and testing of these releases and requires a lot of release coordination, resulting in long lead times and the inability to release frequently. And this leads into the cycle repeating.

    So what are the countermeasures needed to break this cycle?  They include:

    • Smaller batch sizes
    • Architectural, design and development decoupling techniques
    • Increased automation
    • Readiness-based release capability

    Smaller batch sizes require applying MVP (minimal viable product) techniques. When IT gains the trust of the business to deliver more frequently, the business will be more open to focus on the minimal product set of highest priority items it believes can deliver business value. Accelerated delivery provides the ability to test business hypotheses and gain feedback from customers more quickly to determine what worked and what needs changed. The enterprises that can turn this crank more quickly gain a huge advantage in the marketplace.

    Modern web architecture techniques (e.g. microservices, APIs), along with design techniques such as feature toggling to enable dark- and canary-launching allow applications to be deployed independently and with direct control of customer impacts. This increases development velocity due to simplifying and reducing the lifespan for managing feature or release branches in the code base.

    Increased automation combined with a move to readiness based releases allows application releases to be deployed when ready rather than waiting for calendar-based change windows. They key here is not sacrificing quality, auditability or security but rather building those capabilities into your applications and delivery pipeline and requiring those certifications are earned before an application can be released.

    About the Author / Carmen DeArdo

    Carmen-DeArdo-sqCarmen DeArdo is the director of Build Technologies at Nationwide Insurance. He is responsible for helping drive accelerated delivery utilizing Lean and DevOps techniques across the end-to-end delivery value stream.  One current focus area is the creation of an integrated delivery pipeline capability.

  • 5 Reasons Why Companies Should Analyze Their Logs

    5 Reasons Why Companies Should Analyze Their Logs

    At first thought it might seem as though analyzing logs is something that only affects the IT portion of your business. However, nothing could be further from the truth. In reality, log analysis affects every aspect of your business. This includes finance, legal, human resources, sales and marketing, security and operations. In fact, with log analysis, you’ll discover issues either before or as they happen and avoid both lost time and unnecessary delays.

    There are many benefits to properly analyzing your logs. Your organization can increase revenue, reduce expenses, better manage employees, respond to incidents and even keep yourself out of legal hot water. Read on to learn about the five major business areas impacted by log analysis and why every business needs to analyze its log—and the sooner the better.

    Business Operations

    Probably the most obvious use of log analysis is in supporting business operations. These functions include the following:

    • Detecting critical system errors
    • Identifying key trends
    • Improving operational efficiency
    • Supporting service level agreements (SLA)
    • System troubleshooting

    Early indication of problems can pinpoint money-wasting processes. It also can mitigate risk in support of business continuity. This will help avoid service disruptions that can lead to unhappy customers and lost sales.

    Compliance and Legal

    Every organization has internal policies: security policies, employee policies, legal policies, etc. In fact, most organizations have regulations (such as HIPAA and Sarbanes-Oxley) they must adhere to. Often these regulations are imposed by the government. The only feasible way to ensure policies are followed and regulations are met is through log analysis.

    Log analysis simplifies compliance. It also supports audit requirements, litigation needs, subpoena requests and forensic investigations. In short, log analysis is the only way to ensure an organization stays out of legal trouble.

    Proper Resource Sizing

    One of the worst things any company can do is have the wrong amount of resources to support its business operations. From network bandwidth to storage capacity to CPU cycles, businesses have to get these quantities just right. Not enough resources in any area can lead to poor performance, frustrated customers and, eventually, lost sales.

    Of course, the easy thing to do is just overspec these resources. However, doing that leads to increased expenses, which adversely impact the bottom line. Using logs to determine proper resource sizing is the only way to ensure you have maximized your profits.

    The use of logs can also be used to verify third-party billing. For instance, your company can use your logs to make sure the amount of bandwidth you were charged for by your service provider is actually the amount you used. This, too, can benefit the bottom line.

    Sales and Marketing

    It may not seem as though log analysis can be used to directly impact sales and marketing, but it certainly can. For starters, log analysis can be used to quantify the effectiveness of a sales campaign. Information such as referring sites, pages accessed and conversion rates all can be used to tweak different aspects of the sales effort.

    Log analysis also can be used to optimize website performance in the support of a sales funnel. Information such as customer navigation, traffic loads and conversion errors can be used to improve the sales process. In fact, analyzing logs can be used as a revenue driver in any organization.

    Security

    One of the most important areas in any business today is security. Logs can be used to both proactively protect an organization, as well as forensically investigate security breaches.

    Proactively, logs can be used to accomplish the following:

    • Optimize blocking and filtering of incoming traffic
    • Maximize email virus protection
    • Monitor failed authentication attempts
    • Verify configurations in firewalls

    After the fact, logs can be used to do the following:

    • Assess security policy compliance
    • Initiate incident response
    • Investigate security breaches

    You cannot understand security risks or respond to security incidents without the ability to analyze your logs.

    In short, whether you were aware to it or not, log analysis impacts every department in your organization. It directly and indirectly impacts every company’s bottom line by increasing revenue, decreasing expenses and delighting customers.

    You now know that log analysis is not just a “back office” IT function. Every department in your company needs to use the intelligence contained in your logs to do their jobs better. It is why every business needs to analyze their logs, and now is the time to start.

    About the Author / Ariel Assaraf

    arielassarafAriel Assaraf is a co-founder and CPO at Coralogix. Previously Ariel was a GL at Verint and a Product manager at an elite Israeli intelligence unit.  He is into Software design, UX, growth hacking and basketball. Ariel holds a BEc in Economics and Math from the Open university of Israel. Connect with him on LinkedIn and Twitter