devopsy.kinsta.cloud

Category: Blogs

Five mistakes enterprises make while implementing automation

Automation, if done right, can add a ton of value to an IT organization. Benefits include speed, quality, and improved productivity. But only a few IT organizations have been able to truly reap the benefits of it. Why is that? What is it that these successful companies do differently while others continue to struggle?

Here are 5 of the most common mistakes we see when organizations try to implement automation.

1. Automating Infrequent Activities

Automation works best when a manual task is well defined, predictable, and highly repetitive. The first two dimensions are key in determining if an activity can be automated. The third helps determine if it is worth automating. Yet when organizations decide to automate, they focus on the first two and rarely consider the third.

For example, automating code builds is a popular activity to automate. It clearly meets the first two dimensions. But if the project plan only calls for monthly builds…what is the point? At best all you have done is saved the developers a few hours of work. However, if the same automation is used for projects that require daily / weekly code builds. Now you are literally eliminating hours of work. Translate that to annual effort saved and you end up moving the needle.

2. Automating In Silos

Hand offs are the silent killers of efficiency. However, most IT organizations are arranged as a series of hand offs (silos) – from requirement to development to testing to operations. And like most silos, the focus is inward, resulting in optimized silos but sub optimized end to end process. No wonder it takes weeks to get a new code through all the way to production with, in many cases, sub-par quality.

The true value of automation kicks in when you stich various activities into a single process, that minimizes / eliminates hand offs, and orchestrates it across silos. In essence, you are not just automating the activities but also automating the hand offs. This in essence, is the heart of the entire DevOps movement. To break down the silos, re-engineer, and automate the process.

3. Forgetting To Reengineer the Process

If you look at the data, most processes follow the classic 80/20 rule. 20% of the process time is spent on performing actual “work”, 80% of the time is wasted on motion. Case in point…it used to take us days (sometime weeks) to open up a simple IP port. The actual time to perform the work takes only about 5 – 10 mins, however getting the work to the SME literally took days (creating tickets, routing, approvals, finding SMEs etc.).

Despite this fact, many organizations spend countless hours finding, agonizing, and optimizing the “perfect” tool (hint: there is’nt one) and spend little to no time on process. In essence, if all you to is focus on the tool, then all you have done is optimize the 20%. No wonder organizations scratch their heads when they put in automation and don’t get the expected results. Automation and process reengineering are like two sides of a coin. If you are truly looking to transform, you cannot have one without another.

4. Not Planning For The Long Tail Of Automation

Pssst…let me tell you a secret. Creating automation scripts is easy…. after all it is the sexy part of automation. The real heavy lifting begins once you have created it and now you have to constantly tweak and maintain it.

Applications and its components, for better or for worse, are constantly changing. Which means that the scripts have to be constantly tweaked. Yet few consider the after math. In fact, our clients have so many scripts that they simply don’t know what to do with it. A better solution is to plan for the long tail ahead of time, set up a governance model that is responsible for updating, maintaining, and pruning the scripts and in turn protecting the investment that they have already made.

5. Fear That Automation Will Take Their Work Away

Fact – many of our clients are leery about automation. Not because they feel it will not work, but are afraid that it will work too well. And that success will eventually lead to good people losing their jobs.

There are three key issues with this line of thinking. First, the assumption is simply incorrect. While automation will eliminate certain types of tasks it also creates new type of work. After all you need someone to manage the automation. Second, the genie is already out of the bottle. Automation is here to stay. Ignoring it will only make catching up to it harder. And third, not implementing automation may have the exact opposite effect and speed up unemployment. Look at Netflix (poster child for automation) vs. BlockBuster. A better strategy is to start small now, while the industry is still trying to figure it out, and try to get ahead of the curve.

Mustafa Kapadia is the Service Line Leader for IBM’s DevOps practice, a business advisory practice focused on helping large enterprises transform their software & application delivery. He has over 17+ years of experience in the tech. space, both as a service provider and a management consultant.

His expertise is in DevOps, cloud, lean, application development, outsourcing, offshoring etc. and has published several articles on DevOps. He lives in San Francisco Bay Area, is an avid blogger (when time permits), a speaker, and advisor to start ups.

You can follow Mustafa on LinkedIn: https://www.linkedin.com/in/kapadiamustafa and Twitter: https://twitter.com/mkapadiatweets

July 21, 2015
Ten ways DevOps will benefit your IT department
When implemented properly, DevOps can transform your software engineering process and create value for both employees and customers, producing business performance and value.

A fully working DevOps methodology will bring the following benefits:
1. Increased service quality
Perceived service quality and reliability depend on both the availability of a service in the absence of error (MTTF: Mean-Time-To-Failure) and the ability to restore the service to an error-free-state (MTTR: Mean-Time-To-Repair).

Due to fast feedback loops and high release velocity, service deficiencies are removed much faster than in the past (shortened MTTR), which leads to an improvement of perceived service quality and reliability.
1. Increased reliability of service delivery
The perceived timeliness of delivery is an extremely important satisfaction factor for your internal or external customers Usable results are delivered early and frequently, which is critical in uncertain and changing business environments.

With agile and DevOps, big projects are cut into small chunks, which are then continuously delivered. Both initial and successive requirements and changes are delivered with short lead times, while changes are possible at any time in the process.
1. Increased customer value through responsiveness to change
To stay relevant, businesses need to constantly adopt to a rapidly changing market environment, respond to competitors and stay ahead in the innovation cycle. Your business needs to act in a world of uncertainty.

This means that at the time a new idea is brought up, most of the project details cannot be known. Even once they are defined later on, they are subject to constant change. Complex upfront specifications – a necessary deliverable in the absence of short release cycles – often become obsolete.
1. Better usability increases customer satisfaction
Shorter release cycles lead to shorter feedback cycles. Your customers are receiving frequent and timely updates, which gives you the ability to evaluate and test their satisfaction and response early on.

You can even test different versions of your product at the same time with different customer groups by A/B testing. This gives you the ability to compare different new features or capabilities of your products to each other.
1. Efficient operations
Agile and DevOps are built on lean principles. The reduction of waste, such as unnecessary waiting times or process overhead through continuous improvement, is a core principle.

This not only helps agility, but also has a positive impact on costs by helps to limit their growth.
1. Reduce bottlenecks through cross-pollination of skills
Blurring the line between dev and ops involves each side learning about the other’s trade. This enables staff to understand the whole process end-to-end and see where it can be tweaked and improved.

If ops know the basics of coding and vice-versa, bottlenecks can be removed by not having to rely on highly specialized individuals. Automation also helps here, for instance in the way a dev can use a service catalogue within ServiceNow to spin up environments on demand, without waiting for an ops member to have free time.
1. Holistic value creation increases employee satisfaction
In a conventional IT organization, both dev and ops are often limited to executing specialized tasks. The value these tasks create for customers is often difficult for customers to measure, as it is one small aspect of a complex process.

Whether internal or external customers are served, the impact created by agile dev and ops teams is far more direct and holistic and can thus be more easily observed and “felt” by employees.
1. Collaboration improves employee attitude
Whereas previously dev would hand code over to ops then switch to the next project, DevOps encourages collaboration throughout the team along the entire process. Not just exchanging emails, but face-to-face and through collaborative devices such as Kanban boards and Scrum meetings.

In the past, the two teams could have been working in different offices. DevOps brings IT together, and this shift in culture is likely to spread outside the department. This reduces waste through misaligned incentives causing political behaviour and mutual blame and increases employee satisfaction.
1. Constant learning and improvement
DevOps promotes a culture of continuous learning and improvement through lean principles. In a fast-moving and unpredictable environment, continuous improvement is the single most important source of sustained competitive advantage and superior economic value.

An continuous learning environment also attracts and sustains outstanding talent. It is an important ingredient to employee satisfaction.
1. Reinvigorate your employees
Apart from the new technical practices DevOps brings, perhaps one of the main advantages for IT is the shake-up it gives working lives. Like a new sports coach can bring a fresh perspective and increased work-rate amongst the team, so DevOps can reinvigorate software engineering teams.

New people to interact with, perhaps even a new office and a new way of working – DevOps can be just what IT needs to breathe life into stagnating staff who have been following the same routine for far too long.

**************************

In order find out how to implement DevOps in your IT department and see these benefits for yourself, I recommend attending my free webinar on Tuesday 28^th July. Click to find out more.
July 20, 2015
The Cost to DevOps: 27 Mufflers

Imagine

Imagine that you are designing the 2016 Range Rover line of sport utility vehicles. Like all gas powered vehicles, each one needs an exhaust muffler. Range Rover likely has narrowed in on a preferred provider of mufflers. But imagine what would happen if the designers and factory line workers could pick from any one of 27 past versions of that muffler from their preferred provider for the new model year. Yup, choose any one — even if it is outdated, lower performance, does not meet current emission standards, or has a known defect. Order it, place it on the vehicle, then ship it.

We all realize this scenario would never happen. No one would select a known defective part for the product they are manufacturing. And who would knowingly choose the 10 year old version of a muffler without the latest advancements to support air quality? No organization would give a each of their designers and line workers free reign on procuring any one of 27 different mufflers for a single model year. Imagine the operational cost of testing the different mufflers. Imagine the maintenance cost of having different versions of the same part shipping. Worse yet, imagine the liability of shipping parts with known defects.

Land Rover is not taking this approach, but software development teams are.

27 Versions

My latest research report, the 2015 State of the Software Supply Chain, reveals that large software development organizations sourced an average of 27 different versions of open source components that they used in development last year. To be more specific, out of the top 100 open source components these companies downloaded from the internet in 2014, they averaged 27 versions of each component.

While auto manufacturers like Land Rover have preferred suppliers of vetted parts, the procurement of open source components is often more of a free-for-all. If an organization has 300 developers, they effectively have a procurement department of 300 for sourcing externally developed software components. If you have 4,000 developers, you have 4,000 performing procurement. Even as we all know only the latest version of a components is the most feature rich and of the highest quality and integrity.

Not all organizations allow free-for-all sourcing practices for components. Fifty-seven percent (57%) have open source policies in place as a method to guide developers toward higher quality parts with the fewest known defects or security vulnerabilities. Organizations like Google mandate the use of no more than two versions of a given open source component across their development teams.

Good Cost, Bad Cost

What does this mean for a software development organization — especially one focused on improving it’s DevOps practices? First the good news: developers are using open source components to speed time to release and improve innovation. Both good things.

The bad news: Organizations are building mountains of technical debt through poor software supply chain practices by sourcing an average of 27 versions of the same component, impacting quality, complexity, maintainability, supportability, etc. They are doing this across the top 100 components being downloaded in a single year which equates to managing over 2700 different versions (when an optimized practice would only require the 100 best).

Organizations are sourcing component “parts” for use in their applications that have up to 26 known better versions available (more features, fewer bugs, improved performance, etc.).

Organizations are downloading and using parts that are sometimes 9 years old, or even older (simple math: open source projects release 3 – 4 new versions of their components each year). They are electively using outdated parts.

Organizations are also downloading some versions with known, documented security vulnerabilities. They are electively using known vulnerable parts.

Net Innovation Through Improved Sourcing

While we often hear people tout a DevOps mantra of “even faster”, there is a consequence to pursuing speed at any cost: technical and security debt.

Open source components are enablers of speed. But free-for-all sourcing and use practices, add to technical and security debt that reduces “net innovation” and adds to the cost of operations. As technical debt grows, net innovation and business value drops.

Image source: http://joapen.com/blog/2014/06/17/how-to-monetize-application-technical-debt/

If reducing the use 2,700 versions of 100 components was not motivating enough, consider this: the research also revealed that large development teams were consuming software components from over 7,600 external open source projects (suppliers). Including all versions of those components, they average organization consumed nearly 19,000 unique components in 2014.

Improved sourcing practices are just part of the overall story for improving net innovation and increasing business value. Improved sourcing practices can also enable more efficient operations, reduce mean times to remediation, and eliminate unplanned work for many DevOps practices. Improved sourcing practices have been employed across many industries resulting in sustained competitive advantages. Improved sourcing practices are part of a broader software supply chain management strategy.

Continuous Learning

There are so many lessons we can learn from other industries who have automated and optimized their supply chains — like Land Rover and other auto manufacturers. I’ll be sharing more of those lessons and perspectives from the 2015 State of the Software Supply Chain here this summer as well as expanding the discussion around “net innovation”. Stay tuned.

July 20, 2015
DevOps will bring about the end of the human race

DevOps will mean the end of mankind.

Sure, it seems great now. Organizations can operate more efficiently. Routine tasks are automated. Development, deployment, integration, monitoring, and testing are all happening in continuously continuous harmony, freeing people up to focus on larger, more important things and continue to grow the business. What’s not to love about DevOps?

Well, all of that seems fine at face value—but eventually it could be the catalyst that brings about SkyNet from the movie The Terminator and enslaves the human race to our Matrix overlords. DevOps is the missing piece that will enable technology to take over the world.

Wikipedia defines the Technological Singularity as:

The technological singularity is the hypothetical advent of artificial general intelligence (also known as “strong AI”). Such a computer, computer network, or robot would theoretically be capable of recursive self-improvement (redesigning itself), or of designing and building computers or robots better than itself. Repetitions of this cycle would likely result in a runaway effect — an intelligence explosion — where smart machines design successive generations of increasingly powerful machines, creating intelligence far exceeding human intellectual capacity and control. Because the capabilities of such a superintelligence may be impossible for a human to comprehend, the technological singularity is an occurrence beyond which events may become unpredictable, unfavorable, or even unfathomable.

We already have robots and drones capable of physical movement / action, and we have machine intelligence approaching full artificial intelligence. DevOps—with its continuous monitoring, continuous deployment, continuous integration, etc, all automated to essentially self-diagnose and self-heal—will be the glue that connects the artificial intelligence with the robot technologies. If the machines can plan and organize on their own, and have the connectivity to communicate with and control physical objects, and can automate most of the grunt-work through DevOps tools and practices the humans end up just being in the way.

“Let’s face it. Humans are complicated. And human-driven release processes even more so. We find too many bugs in production code, performance is unacceptably sluggish, and breakages from manual handoffs are always holding us back. We need to let the machines handle these things so we can deploy production software that’s error-free and lightning-fast,” explained Alon Girmonsky, Founder & CEO, BlazeMeter. “With the full automation provided by Continuous Delivery and Deployment, we can finally achieve properly efficient operations.”

Girmonsky added, “How can we expect the Singularity to come anytime soon with these clunky, error-prone, human-driven deployment processes?”

Not everyone is so anxious for the advent of the Singularity, though. Jay Wampold, VP of Marketing at Chef, told me “We’ve never announced it, but we built a Singularity Kill Switch into our software for exactly this scenario. The truth is our work is more interesting when it involves humans. The cultural aspects of DevOps are more important than technology when it comes to achieving great business outcomes.”

DevOps is awesome right now and everyone is happily jumping on the microservices bandwagon and embracing container technologies with both arms. As more things become continuously automated it is becoming painfully obvious that the one remaining bottleneck—the inefficient element of the whole process—is the biological human units that keep screwing things up.

Coincidentally, I saw a quote recently that sums things up nicely: “From the machine’s point of view, The Matrix is just a cautionary tale on the importance of securing your wireless network.”

DevOps may well be the catalyst that enables technology to rule the world. Whether it’s a benign evolution that eventually results in catastrophic consequences, or a well-orchestrated distraction by the technology we rely on—part of the early stages of the strategy to eliminate mankind—we might be on the path to the end of the human race.

July 16, 2015
Microservices define the next era of IT

There is a lot of focus on DevOps and container technologies these days. Both are very strong trends in IT on their own, but each is also proof of a larger shift in IT culture to a microservices architecture. A new report from IDC titled “The Emergence of Microservices as a New Architectural Approach to Building New Software Systems” takes a closer look at the evolution and impact of microservices.

Let’s start with the obvious question: What exactly is microservices? “Microservices is an architectural approach that draws on long evolving experience in software engineering and system design, including the SOA efforts of the last two decades,” said Al Hilwa, research director, Application Development Software at IDC. “Microservices architecture is enabled by a spectrum of tools categories but is primarily an architectural approach to system design that also requires considerable organizational and cultural adjustment to execute successfully.”

Put another way, microservices is an umbrella term that applies to breaking systems and applications down to a more granular, modular level. Containers are an example of taking an application and making it into a self-contained component, and DevOps provides the framework for developing, deploying, and managing the container ecosystem.

By some interpretations microservices and containers are somewhat synonymous. In other words, microservices is just another way of saying that an organization is using container technologies for app development and deployment. IDC classifies microservices more broadly, saying it is based on an approach to organizing software development—more of a concept and less of an actual product or technology.

The Wikipedia definition of microservices sums it up like this: “In computing, microservices is a software architecture style, in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs. These services are small, highly decoupled and focus on doing a small task.”

Although the concept of microservices is broader than the underlying platforms or tools it uses, IDC acknowledges that the advancements in software development and deployment methodologies—namely DevOps and container technologies—has played a pivotal role in elevating microservices to where it is today.

The transition from a traditional hardware server infrastructure in an on-premise datacenter to a cloud-based, software-defined infrastructure that can be created, modified, or removed programmatically offers significant benefits for organizations. The microservices architecture enables companies to be much more agile and cut costs at the same time.

There are some challenges and concerns as well, though. Hilwa notes, “Microservices architecture, by its very nature, is distributed and operates across networks and can thus exact significant performance penalties that must be accommodated with architectural solutions, like caching layers and API management and optimization techniques.”

In the IDC report Hilwa talks about the need for strong organizational support and an overall shift in the IT culture in order to succeed with microservices. As Hilwa puts it, “Organizations have to increase their tolerance for risk and learn to fail gracefully, fast and often in order to achieve success.”

Hilwa provides a comprehensive overview of the current state of microservices in the report along with some prescriptive guidance for organizations that are either just trying to understand what microservices is, or those that have already waded into microservices but want a better appreciation for the benefits and pitfalls.

July 15, 2015
The Whole Nine Yards with DevOps and Agile Operations
Growing up as a boy in Manchester, UK, football (ok, soccer to US readers) was everything to me. I vividly remember being herded into the stadium stands on cold rainy Saturday afternoons to watch my team (#MCFC) win, draw or lose. Back then, football was for the die-hards – no frills or fancy tech, just hot tea and a suspect meat pie at half-time.

How things have changed. Now sporting events have undergone a complete transformation – all digitally-driven.

High Tech Sports

Take Levi Stadium, home of the San Francisco 49ers for example; considered by many to be the most high-tech stadium in the world. There’s too much tech to describe in detail, but you can be sure that all the Wi-Fi beacons, 400 miles of cable, photo voltaic energy and a funky mobile app have been designed with one thing in mind – enhancing the fan experience. So no ‘cattle-herding’ at a 49ers game – nope, a personalized digital experience that’ll find you your seat, food concessions, the closest bathroom — and of course the shortest beer line (#1 feature in my opinion).

Levi Stadium isn’t just another example of technical wizardry. It’s more an exercise in an organization deeply connecting with its customers through the delivery of highly experiential services. Understanding the needs, motivations and desires of their loyal fan base and servicing them accordingly.

It’s a pity this same thinking isn’t always applied in IT Operations – that is, deeply understanding what Ops ‘fans’ need if they’re to ensure a good business user and customer experience across new highly dynamic agile environments.

High Stakes IT Operations

Similar to the Manchester game day experience years ago, IT Operations has often done it tough. They’ve worked in isolated NOC’s and service centers, been placed on 24/7 call; working weekends and missing their kid’s birthdays. They have been served specialized ‘team merchandise’ in the shape of complex tools and processes – always counting on their loyalty to save the day when the next mega release comes over the wall. No great surprise then that Operations in many organizations is seen as uncommunicative and uncompromising – almost, well – tribal.

But IT tribalism doesn’t win matches in the software-driven economy game. Now, digital business realities means IT Operations must supplement its traditional fixation on reliability and resilience with a willingness to drive change – Operations must itself become more Agile. But how do you start? Thinking back to the innovation at Levi Stadium, here are three good ways.
1. Gaining Loyal Supporters – Development and Operations aren’t enemies, but like rival UK football team supporters the teams are often segregated. Dev and their tools to the left, Ops with theirs to the right. From a business perspective this is plain dumb – especially when it comes to getting the most value from technologies like application performance management. Rather than frantically monitor applications as problems manifest in production and then call Dev for help, wouldn’t it be better to incorporate operational intelligence much earlier in the software lifecycle? So when code is released, monitoring could immediately provide development with an early warning on operational issues. Conversely, Ops practitioners gain accurate and timely insights into production performance requirements and KPI’s – that’s not only a DevOps style win-win, it’s an agile like best practice to increase quality and avoid technical debt.
1. Filling the Business Stadium – The goal of Operations has always been keeping the business lights on, but Agile Operations now means making them shine brighter. Cloud, Microservices architecture and containers all give businesses the technical clout needed to support speed at scale, but it comes at a cost. Today’s sophisticated applications rely on specialized technologies, so it’s perhaps understandable that Operations chase the technology down the proverbial rabbit hole with more specialized tools. But the real truth is that any monitoring system which doesn’t deliver true business value by providing unified insight into how customers are actually experiencing IT services is of no use to anyone. Remember too that technology scale is about future proofing your business, so look for scalable monitoring to match it.
1. Delivering a Complete Experience – The digital experience for a 49ers fan doesn’t start and end on game day. It is delivered by a linked series of services – a digital journey comprising seat selection, ticketing, parking, entry, action replays, and player stats reviews – every one of which can positively or negatively impact the fans experience. Whatever your industry, IT Operations will be called upon to support similar services, meaning deep and uninterrupted visibility across the myriad of front and back technologies underpinning every customer interaction, engagement and transaction will become essential.
Successful digital transformation needs more DevOps and agile operations, agile development, faster release cycles and higher quality software. It’s time for IT Operations to stop fixing production problems and become an active participant in supporting these goals. Without Agile Operations, your role in the software-driven business game ferociously being played out will be like that meat pie I ate many years ago – suspect.
July 15, 2015
Bring Your Own Exploit

Here’s a simple question: for each tool that your organization uses, have you (or someone else on your DevOps team) changed the default passwords? That should be a no-brainer, shouldn’t it? Of course you changed them! Or at least you changed them for the tools that looked like they would have default passwords. Well, OK, at least the ones that looked like they might present an obvious security risk — and where you noticed that there was a default password. Would those other tools even provide an intruder with a useable exploit?

(more…)

July 14, 2015
Lean for DevOps: Mapping the tributaries and deltas of demand
Here at IBM’s Lean practice we use a diagram called ‘Mississippi’ to analyze demand. It is not so-called because it originates in Mississippi – in fact I’ve been given to understand that this tool was developed, and named, in our UK practice*. Instead, it’s called the Mississippi because, like that great river, demand comes from many different sources (or tributaries) and can leave a process through a number of different points (the delta). And, apparently, at times the Mississippi delta reflects tidal patterns and flows upstream. In the same way, demand can route back into, or upstream within, a process – for example, in the shape of rework.

We want to analyze the volume and frequency of demand for a number of reasons. Understanding demand helps us to:
- Identify ‘runners’ (everyday requests), ‘repeaters’ (less frequent, but not unusual requests) and ‘rarities’ (infrequent requests). This might be in terms of user groups, applications, or type of request (for example – small changes vs major project). When we design our improved future state, we will design it for runners and repeaters. Sometimes the impact of exceptions can be so painful, team’s lose sight of how infrequent they are, and design a process to prevent or manage those rarities – which will be inefficient for all those runners and repeaters.
- Identify failure demand – Where are additional requests re-entering the process, as rework? Where is there process activity which doesn’t ‘go anywhere’?
- Illustrate channels in and out of the process, so we can identify potential control points, or illuminate a lack of filter, and see where demand might be routed in via unexpected channels.
- Tell us what we don’t know: which elements of demand are we unaware of? We need to understand all demand so that we can build and resource (load level) a process which can meet that demand. Sometimes finding out what we don’t know is a lesson in itself.
These benefits are as relevant to Lean for DevOps as in any other area.

It’s hard to say what you’ll learn from conducting this analysis, until you’ve done it, as every Mississippi is different. But to demonstrate some of the valuable lessons I’ve learned from drawing up Mississippis, here are some real life examples:

Lightbulb moment: ‘Churn is a fact of life – we need a better way to handle it’

Lightbulb moment: ‘We need to start saying no to enhancement requests’

Lightbulb moment: ‘We have way too many changes taking the emergency route: a faster ‘normal’ route will reduce that demand and the associated risk.’

In their different ways, each of these helped make the case for a shortening of the SDLC, closer coupling of development to business demand, and a more nimble deployment process.

*If you’ve seen this in use outside of an IBM engagement, I’d love to hear about it! Find me on Twitter to set the record straight.
July 14, 2015
Webinar: Introducing CloudBees Jenkins Platform – your foundation for DevOps and CD with Docker Containers

Continuous delivery (CD) of applications is rapidly becoming a differentiator in this application economy. CloudBees, the enterprise Jenkins company, recently announced the availability of the CloudBees Jenkins Platform to help organizations adopt CD. This new enterprise offering from CloudBees brings CD to the masses with the new Team Edition, while enabling enterprise CD deployments powered by Jenkins at scale with the Enterprise Edition. At the same time, the Jenkins open source community, in conjunction with CloudBees, released six new plugins to support the use of Docker containers within Jenkins-powered CD and CI processes. Docker is powerful new technology that allows teams focused on delivering software to standardize their development and production application environments for reduced risk and accelerated application delivery. Leveraging Docker containers in a CD process managed by Jenkins is the ultimate way to deliver better software faster.

Join Tracy from CloudBees as she talks about Cloudbees’ new enterprise offering and the changes happening in the Jenkins community to provide first class support for Docker in the creation of CD pipelines. In this webinar, Tracy will introduce features in the latest release of the CloudBees Jenkins Platform to
help manage Jenkins’ across the organization and walk through six common delivery patterns with Jenkins and Docker. Tracy will then tie it all together with a demo of an end-to-end delivery pipeline with Docker.

Continuous delivery with Jenkins and application containerization with Docker are rapidly becoming two of the foundations of the DevOps movement. Check out this webinar to learn how you can adopt these new tools and techniques in your own DevOps transformation.

Recorded: Wednesday, August 5th, 2015

Recording

Slides

[seoslides embed_id=”3285347f9c95″ script_src=”https://devopsy.kinsta.cloud/embed-script/cloudbees-jenkins/8856/” overview_src=”https://devopsy.kinsta.cloud/slides/cloudbees-jenkins/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”Cloudbees – Jenkins” /]

Your Host

Alan Shimel, Editor-in-Chief DevOps.com, An often-cited personality in the security and technology community and a sought-after speaker at industry and government events, Alan has helped build several successful technology companies by combining a strong business background with a deep knowledge of technology.

About the Panelists

Tracy Kennedy is an associate product manager for CloudBees and is based in Richmond, Virginia. Prior to her current role, Tracy has worked at CloudBees as a solutions architect and a developer success engineer. In her free time, she enjoys rock climbing, grand strategy games, and reading. Read more about Tracy in her Meet the Bees blog post and follow her on Twitter.

Udaypal Aarkoti is the Director of Solution Architecture at CloudBees. He believes in complete end to end automation and that continuous delivery is the future of application delivery. Prior to CloudBees he lead the middleware solution architecture team at Red Hat.

July 13, 2015
How Continuous Delivery is Changing Software Development

When you start to implement a new methodology, it’s very easy to get bogged down by the specifics and lose sight of the overall goal. With Continuous Delivery, we see endless debate about whether to use Puppet, Chef, or Salt for deployment, or discussion about how to build a CD pipeline with containers. These are just technical challenges to overcome. They’re implementation details that have little to do with why CD is such a powerful choice for businesses.

What’s the most important metric for your software? It’s not the speed of delivery, the number of features, the performance under load, or the defect count. It’s end user satisfaction. The question you need to ask and keep asking is – How well does your software cater for the people using it?

The CD mindset keeps you laser-focused on that metric in two very important ways.

Real representation for the end user

Too many organizations are still just paying lip service to this concept. The developers and testers working on a piece of software often have no contact with end users, and that can mean that they have very little idea about their needs. If you really want to create a great piece of software for someone, then you have to understand how they work. What are their requirements and constraints?

Traditionally, software development has been siloed. Individual departments have focused on their own tasks first. Developers may be delighted with their clean repository layout. QA may be satisfied with how complete the test coverage is. But neither of these things tells you about the end user experience. The system may be completely unusable.

Personal contact is a great idea. If your team actually talks directly to end users, asks questions, and learns to empathize, then you’ll see the benefit in the product.

CD also encourages greater visibility. Not just oversight for management, but for the whole team. Everyone, from development, through QA and operations, to the actual end users should get a look at how the overall service is being put together and delivered. Have channels in place so that anyone can contribute to service improvements, regardless of their area or expertise. Greater visibility over the process, and an ability to influence it, makes for a really cohesive, motivated team.

Collecting, analyzing, and acting on the right data

You can empower everyone on the team to make suggestions and you can say that end user satisfaction is paramount, but without collecting the right data you aren’t going to be able to realize the benefits of this approach. You need help understanding where the opportunities for improvement are, and it’s vital to measure the impact of what you’re doing.

In the big data age, it’s common for companies to collect all sorts of statistics. It’s easy to automate the capture of technical operational details such as CPU load or memory usage, but how much do they really tell you? Though it may be more challenging to find out whether your end users are satisfied, it’s also a lot more important.

Eliminate the risks of educated guesses and gut feelings. Apply a solid methodology to improve your service based on user feedback, just as you hone technical performance based on technical data. You don’t need to spend hours brainstorming new features. You can analyze end user interaction, find a pain point, create a hypothesis about the cause, tweak the system to address it, deploy the change, and measure how it really performs.

Adopting this process and repeating it over and over will improve your service. Because you’re rolling out small changes, it can be done quickly and efficiently, with easy rollback if required. As long as you’re careful to measure your hypothesis and the effectiveness of your solution each time, there’s no downside.

The ideas here are nothing new. Your marketing department most likely already conducts A/B testing and measures user interaction. But how many companies are really taking the holistic approach, applying these concepts also to software development and delivery?

To make the end user the focus, and really leverage the potential of Continuous Delivery, the whole team has to pull in the same direction. Agile and CD methodologies help you cut down barriers, set shared goals, and keep the focus firmly on the customer to revolutionize the way software is delivered for the people who need it.

About the Author/Andrew Phillips

Andrew Phillips heads up product management at XebiaLabs, a provider of continuous delivery automation. Andrew is an evangelist and thought leader in the DevOps, Cloud and Continuous Delivery space. He sits on the management team and drives product direction, positioning and planning.

July 13, 2015