devopsy.kinsta.cloud

Category: Blogs

  • How Mature Is Your Automation Strategy?

    How Mature Is Your Automation Strategy?

    Working in Operations can sometimes feel like walking up a down escalator. The business puts relentless pressure on your team to overcome bottlenecks, accelerate the overall delivery process and grow the volume and frequency of deployments. You’re also faced with a growing number of service level requirements and demand for higher release velocity—all stretched across different platforms and increasingly complex deployment scenarios, on premise or hybrid.

    The answer to these challenges is IT automation. Scaling your automation not only secures continuous service delivery, it also frees your resources to focus on core activities and industrializes more service management processes, such as self-service portals for infrastructure provisioning.

    However, many organizations are still on low automation maturity levels because of various barriers, including:

    • Organizational inertia
    • Lack of process capability maturity
    • Lack of the right technology expertise
    • Mistrust and fear of getting replaced

    Do you recognize some of these barriers to automate faster, better and more in your organization?

    Here’s the problem: You can determine how much and where that IT automation is needed only after you understand the current state of your automation. Are you still at the manual stage (level 0), copying new release files in the production environment, adjusting parameters and restarting the application service via a management console using manually entered parameters, for example?

    Are you automating repetitive tasks through scripts, but need to do all the preparation work to run the script, frequently modify the scripts and script parameters based on changing context, start scripts manually, monitor their execution individually and look at the outputs each time a script runs? If so, you are on level 1—and you can do much better than that.

    Are you connecting scripts into sequences and deploying new releases using a run book automation tool (level 2), where integration with other tools in the release chain is still manual and context-specific parameters have to be set individually for each execution?

    Or have you scaled the heights of process automation (level 3), where you benefit from the automated deployment of the entire process, including automated retrieval of the right parameters at the right time and in the right context triggering of automated deployments (either using commands or driving run book automation tools), confirming completion and updating records? If so, you are doing very well and can reach the last (final) maturity level by adding dynamic composition and configuration of processes based on the real-time context.

    Understanding your automation status and barriers helps you decide how and where to invest in the next automation steps. Having a baseline means you can build a business case, apply goals and targets to your organization, and measure your success as you progress.

    An Automation Maturity Assessment Service can be applied to create this baseline, identify gaps and provide recommendations, which result in lowering the manual effort and increasing your IT automation maturity and operational efficiency. Consultants initially review your current IT infrastructure and your software delivery processes and release management processes. Next, they perform discovery interviews to gather information on core processes relevant for automation. Services are subsequently rated in terms of their automation maturity and their potential for automation. The qualitative results are then correlated with operational measurements and KPIs to understand the impacts of low maturity on service levels and competitiveness.

    The assessment might find, for example, that your development team changed its deliverable for a particular application to a Docker container, which is currently not integrated in your automation release and deployment process. Your tool already supports Docker, the assessment finds, and it can be easily integrated. The benefit to do this is assessed as ‘medium,’ while the cost is ‘low.’

    Based on the results, a business case can be created or a DevOps roadmap can be crafted.

    You already know the benefits of IT automation. By allowing your automation to mature, you open the door to even greater cost savings, increased efficiency and lower risk.

  • The Pizza Principle

     

    — ROELBOB

  • 4 Tech Imperatives in 2016 to Prepare for Tomorrow

    4 Tech Imperatives in 2016 to Prepare for Tomorrow

    Around the start of every new year come a bevy of predictions about what’s coming (or what someone, or some vendor, or some analyst hopes is coming) in the year ahead. Rather than do that, based on recent conversations with many CIOs, I’ve collected what I think are imperative to-do’s for CIOs and IT leaders to ensure their enterprises can innovate in the years ahead.

    If you don’t already have these in your crosshairs, here are four tech imperatives for 2016:

    Action Item 1: While IoT gets the buzz, groom those mobile app backlogs
    The world has gone mobile. That’s no secret. Mobile analytics firm Flurry found that business productivity apps grew 125 percent in 2015, because most every employee today is armed with a mobile device and more comfortable than ever working on mobile devices. And mobile enterprise investments will continue.

    Currently, however, most enterprises still have considerable mobile backlogs. In the year ahead, it’s imperative they address those backlogs. This investment in mobile apps will continue, so enterprises must clear through the clutter and groom their mobile app backlogs. This year you’ll hear more and more about the Internet of Things, or IoT. (I know, I know, how can we expect to hear more about IoT in ’16 than we did in ’15? Trust me, we will.) Companies first must focus on enterprise and productivity-enhancing apps, while planning and preparing systems and plans for the expansion to IoT.

    In the next few years, IoT will include access to wearables and their data, enterprise office equipment, office buildings, cars and virtually anything else that can be tethered to the Internet. But, for now, the focus for most enterprises must be on clearing their mobile app backlog and grooming their mobile app pipelines, and then setting the stage for the architecture that will be required to support their eventual IoT efforts.

    Action Item 2: Get a tight focus on micromoments
    These days, employees are making every second of the business day count, even when they’re away from their desk. Most employees aren’t sitting, working in front of computer monitors; today, most everyone is on the move and spending more time working on small-screen tablets and smartphones. This has changed how we interact with each other—and our applications.

    Today, workers have short exchanges in text or on social media, short discussions on the phone, and short interactions with their apps. Rather than settling in and computing at a desktop PC, we are computing on our mobile devices while we walk office to office, or are waiting in a conference room for a meeting to start. We are computing, more than ever, in “micromoments.” Guiding developers to develop strategically for mobile is still an imperative for CIOs this year.

    What do I mean? Development teams must ensure their apps are built so users can engage in the context of their moment, based on their location, the task they are undertaking or perhaps the time of the day. Thus, apps must be developed so that data can be entered quickly and easily and consumed readily. And the micromoments app experience must be congruent with those on notebooks and tablets, when people typically are settling in for longer stretches of work and concentration.

    Action Item 3: If enterprises haven’t already, they need to develop their IoT brokers and management platform strategy
    All of those IoT devices we mentioned above will need to be managed. This will require cloud-based platforms that will:

    • look at the data,
    • protect the traffic from being attacked,
    • accept legitimate traffic,
    • dispatch it to where it needs to go,
    • save the appropriate data for long-term analytics,
    • send other data for real-time analytics and response, and
    • enforce security and privacy policies.

    Managing the security, storage and traffic will be a strategic effort in the years ahead, and the groundwork needs to be set sooner rather than later.

    This year is the time to build the strategy for your enterprise’s IoT platform strategy, so the IoT data can be managed properly and management can scale as the use of IoT grows. Think this won’t apply to you? Think again. Gartner predicts that there will be more than 25 billion IoT devices by 2020, up from 4.9 billion today—and a good portion of them will be enterprise IoT devices.

    Action Item 4: Create the data-driven culture
    Big data analytics has touched nearly every aspect of business, from health care, with data-driven medicine saving hundreds of millions annually, to electric utilities managing the grid more intelligently, to helping marketing teams understand and pinpoint their target audiences with more intelligence and precision than ever before possible.

    What’s often forgotten about big data analytics is that success here is about much more than databases, storage, dashboards and data scientists. It’s as much about creating a data-driven culture in which decision-makers in the organization are motivated to make the most of the data and analytics to move the organization forward in the best way possible. Strategically, CIOs want to create this culture, make as much data as possible available to employees, and deliver the data to them in the context of their roles. They want to develop platforms that democratize the data to as many people as possible so they can seek the insight they need.

    Enterprises today already have a lot of the critical data in their software, ERP systems, employees and customers. In the years ahead, IoT devices will create additional tsunamis of data to be analyzed and acted upon for strategic advantage in the earlier years and to simply maintain the status quo in the years beyond. That’s why it’s so important to get this on the strategic radar today.

  • Can We Stop Talking About DevOps?

    Can We Stop Talking About DevOps?

    I first heard the term “DevOps” from a friend in the software business when I was working at Dell HQ in Round Rock, Texas. He recommended I read “The Phoenix Project,” by Gene Kim, Kevin Behr and George Spafford. I did read it and I found it a fascinating story, but as a longtime network administrator (to oversimplify as much as possible) and having never been involved in developing software, I wasn’t quite sure how it applied to me.

    It was enough to pique my interest, though, and drove me to volunteer at a DevOpsDays event in Austin. Within weeks I left Dell and joined a small software company, where I could have a better chance of getting my arms around this slippery pig called DevOps and more hands-on practice with the related tools and techniques.

    So imagine my surprise when a year later, the same old friend who introduced me to DevOps suggested that the end goal of a DevOps transformation should be that we stop talking about DevOps. Uh-oh, I thought, he’s lost the plot. But he made his case by pointing out that adding testers to dev teams—a typical step in any Agile transformation—doesn’t result in new dev test or agile dev teams; they remain simply “dev teams.” Once a business/group has fully internalized the Agile or DevOps values and behaviors, he argued, “working in an Agile or DevOps way” becomes simply “working.”

    This is why many DevOps promoters, myself included, have a negative reaction to seeing “DevOps” in job titles, job descriptions or department names. While it simplifies the job of identifying which job candidates have a DevOps mindset or skill set, it effectively excuses everyone else in the organization from taking responsibility for change. “Doing DevOps” becomes the job of a particular individual, team or department, instead of a philosophy internalized by the organization.

    Of course, the horse is already out of the barn on that one. Each year we see an increase in the number of businesses advertising for DevOps engineers, forming DevOps departments or listing DevOps among the required skills for a position. It doesn’t matter whether we think this is a good thing or bad thing; evolution will take its course and there’s little we can do to stop it. What we can do is observe, acknowledge and adapt.

    Sure, the dangers are real. A DevOps department can easily become just a third silo or the DevOps engineer might become the scapegoat for everything that goes wrong between development and operations. But if a DevOps engineer, VP of DevOps or DevOps department can form, contribute to and/or nurture an environment of increased empathy, faster feedback and continual growth, that’s awesome; put the focus there. Don’t spin your wheels arguing that they just “don’t get it” or “they’re doing it wrong.”

    I’ve spent the past couple years researching, promoting and attempting to practice this thing we call DevOps. While it’s widely believed that DevOps is impossible to define, I am firmly in the camp of those who believe that empathy is, to quote Jeff Sussna, “the essence of DevOps.” Just as the sales team needs to have empathy for its customers, everyone in the value chain needs to have empathy for each other. I’m aware that many people find this term too “touchy-feely,” but the business benefit of more harmonious interaction between one’s teams and between the organization and its customers is clear: The faster and more effective one is at converting solutions into real value for customers, the more successful one will be in the market. Thus, being empathetic isn’t just being a good citizen, it’s also being a good businessperson.

    Taking it a step further, someone on Twitter recently suggested that “DevOps has nothing to do with technology.” The statement seemed ridiculous on its face. After all, the term “DevOps”—literally a portmanteau formed from the words “developers” and “operations”—was coined by Patrick Dubois, a technologist intent on improving the process of building and deploying software. But as I thought about it I started to understand. As the DevOps movement has evolved, the most fundamental components its promoters have identified, from Gene Kim’s “Three Ways” (systems thinking, amplify feedback loops, culture of continual experimentation and learning), to John Willis and Damon Edwards’ CAMS (culture, automation, measurement, sharing), to Dave Zweiback’s ICE (inclusivity, complex systems, empathy), are primarily about how people work. It doesn’t matter if one is building software or running a school—DevOps principles are sound.

    I recently tweeted the observation that “anyone who attempts to define DevOps in a paragraph is trying to sell you something,” adding, “not necessarily a bad thing, just buyer beware.” This wasn’t a criticism of tool providers—many tools, from build automation to log monitoring, are essential to an effective DevOps transformation. It was a reminder that the problems and solutions DevOps is concerned with are complex and nuanced. There is no prescribed tool set or checklist of actions one can take to be successful; an effective DevOps transformation requires thoughtful, committed action across the whole range of people, practices and products one uses in their work.

    It might take months or years of practice, but maybe one day we can all stop talking about DevOps.  

  • Technical Debt

    Technical Debt
    “Debt can build to a point before it needs to be addressed. But as many new to credit cards can attest, ignoring the debt building up won’t make it go away. — Jimmy Bogard, bit.ly/1VNh1ct

    — ROELBOB

  • Only DevOps and Taxes

    Only DevOps and Taxes

    As software eats the world, it’s hard to have a conversation about anything that isn’t directly related to or driven by modern mobile, web and IoT applications. DevOps describes the modern approach to building these applications. But like all new movements, there is a cost. And while some of the costs associated with modern development are not new, it’s becoming more and more clear that DevOps organizations have to pay their tech tax or prepare for trouble.

    (more…)

  • End-User Analytics: A Reality Check to SLAs

    End-User Analytics: A Reality Check to SLAs

    Everyone understands that a great user experience is vital for customers, but few organizations give the same level of consideration to their own employees. This lack of insight into the internal end-user experience leads to frustration, inefficiency and waste. Detailed analysis can lift the curtain, exposing the gap between your service level agreements (SLAs) and the reality of your current systems and software.

    Some of your employees may have more applications than they really need, while others may lack the tools to do their job effectively. It’s also likely that some of your employees are making do with outdated software that’s no longer fit for purpose. Before you can set about changing that, you must gain an understanding of the overall picture.

    What does your user experience look like?
    Many organizations will have trouble answering this question. They may not know how many applications they have, which ones are being used, and how well they’re performing.

    The rise of shadow IT—and the fact that 40 percent of spending no longer controlled by the IT department, according to Gartner’s “How to Manage the IT Budget Wisely Through Cost and Value Optimization,”—are further muddying the waters.

    To determine your company’s user experience, ask yourself the following questions:

    • How many users do you have, and how are their roles defined?
    • What devices are accessing your systems on your daily basis?
    • Where are all the access points located?
    • What content is being accessed?
    • What applications are being used?

    By trimming the unused apps and consolidating common apps through a virtualized XenApp or similar environment, you can redirect resources to focus where they can deliver the greatest benefit.

    SLAs are failing
    It may be tempting to take the SLA model and apply it internally, but SLAs are too simplistic and one-dimensional to deliver the insight that’s required here. Cloud service providers might focus on availability and uptime, but what do those metrics tell you about performance? Issues such as slow-loading pages usually aren’t included in the metrics, but they really should be if you want to assess the user experience.

    There’s also a trust issue here. Can you validate that your service provider is meeting expectations? What about security? Relying on provider self-reporting and a set of metrics that don’t reflect accurately the performance or the user satisfaction with the platform or application are inadequate if you really want to understand what’s going on and act to improve things.

    End-user analytics
    You need insight to real-time and historical data on all your hardware, users and applications across multiple environments inlcuding traditional, mobile and virtual. Good end-user analytics will flag security risks and suspicious behavior, record when an application hangs or crashes, and identify whether specific issues are widespread or localized. Records should be comprehensive enough that you can audit areas of concern and run root cause analysis to find ways to improve. Turn your end users and their devices into roaming sensors, which paint a factual view on usability and performance.

    Finding out how your employees really work is invaluable insight that can streamline many emotional conversations. Finding out what applications and devices they’re using—and how they’re using them—can unlock many potential benefits for different areas of your business. You can ensure costs are kept down and you maintain regulatory compliance while maximizing agility. A fresh insight into risk and productivity will help you to make informed business decisions.

    The end user knows best
    The only real measure of software quality that’s worth its salt is end-user satisfaction. Forget about what applications have been designed to do; forget about developer and service provider promises that don’t include an end-user analytical strategy. Cut to the chase and look at what’s actually happening; analyze every user session and employ business intelligence to extract actionable insights that will have a tangible impact.

    Give users the flexibility they want and the tools they need to do the best job possible. Happy and productive staff are the foundation of a good business. Seek out service providers that provide transparent end-user analytics; this will develop a foundation of trust and collectively you can provide guidance based on factual performance. Hone in on boot times, application performance or network speed: You dictate the metrics that are important to your business and metrics that make a difference to your customers.

    By acting without analyzing and putting your faith in SLAs, you’re basing the company’s future and its future path on pure guesswork. With end-user analytics, you can find out exactly what’s actually needed and ensure that you’re on the right track.

    About the Author
    crop_Nicholas Lee of FujitsuNicholas Lee is head of Global Digital Programs for Fujitsu, the Japanese information and communication technology company.

  • Heroes

    Number-35

    — ROELBOB

  • A Life in Code

    The Lifetime of a Developer
    “There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.” –Frederick P. Brooks, Jr. http://bit.ly/1IOVbPG

    — ROELBOB

  • How DevOps Helps Improve Application Security

    The DevOps trend is gathering pace, evolving from a niche to a mainstream strategy. Organizations are overcoming the barriers to successful implementation and finding real benefits in terms of speed and efficiency. But there are lingering issues to solve with regard to security. As companies look to push more changes to production more quickly, risks increase from multiple areas including integrating third-party software with known vulnerabilities, creating security defects in the code, not being able to fix the security issues that do arise and poor configuration.

    According to the 2015 Cost of Data Breach Study from IBM and the Ponemon Institute, the average total cost of a data breach for participating companies increased 23 percent in the last two years to reach $3.79 million per breach. As DevOps presses ahead, security isn’t being considered often or early enough. Maybe a more “rugged” DevOps approach is needed.

    Building in vulnerabilities

    The vast majority of data breaches last year were entirely preventable. According to Verizon’s 2015 Data Breach Investigations Report, 99.9 percent of the exploited vulnerabilities were compromised more than a year after the Common Vulnerabilities and Exposures database, which lists known information security vulnerabilities and exposures, was published.

    Developers frequently integrate open source code with third-party applications that have known vulnerabilities, providing would-be attackers with a way in. It’s difficult, time-consuming and expensive to close these loopholes after the fact.

    Expand the DevOps mindset

    We see many benefits when development and operations teams work closely together, so perhaps it’s time we applied the same logic to security and risk experts. Putting them into the DevOps mix earlier in the process could lead to an increase in empathy and understanding—and an injection of expertise at the outset that could save a lot of pain later in development.

    Security and risk professionals can work directly with developers and operations to identify and remediate potential vulnerabilities. They can paint a picture of how to decrease the attack surface, set up alerts and boost response times.

    Integrate automated security into your pipeline

    If you can embed security goals into your continuous delivery processes, it should be possible to automate a lot of your security checks. Stick to the same principles as your wider development by making frequent, small, fast improvements to security. Automation can free up your security experts enough to find underlying weaknesses and tackle them.

    The average organization receives almost 17,000 malware alerts in a typical week, but only 19 percent of those are deemed reliable, according to the Ponemon Institute, in this Malware Containment Report. This means two-thirds of security staff time is wasted because of faulty intelligence, at an average annual cost of $1.27 million. Only 41 percent of organizations have automated tools to capture intelligence and assess threats, but those that do report that 60 percent of malware containment can be handled without any human intervention.

    It’s important that security professionals work directly with your developers and operations people to integrate vulnerability tests and security scans into your continuous delivery pipeline. They’re engaged in an ongoing battle with hackers, so make sure to continually review and tweak the tests that are run.

    It also helps to have versioned definitions of all your systems, so you can readily and automatically scan for vulnerable systems when new vulnerabilities are announced.

    Don’t forget to measure

    Testing the effectiveness of your security measures is vital. Run penetration tests and employ destructive testing tools to see how well your processes stand up. Make sure you have clear remediation plans and that you can deploy quickly to roll back or forward to eliminate any vulnerabilities.

    Security is too important to be an afterthought. We know there are lots of benefits to breaking down silos—let’s extend that beyond development and operations to include security. Build it into your continuous delivery pipeline and automate where possible, and you’ll get greater value from your security experts. You’ll also turn out better-quality software.

    About the Author
    cropAndrewPhillipsAndrew Phillips is vice president, DevOps Strategy for XebiaLabs, a provider of automation software for DevOps and Continuous Delivery. He sits on the management team and drives product direction, positioning and planning.