devopsy.kinsta.cloud

Tag: adopting DevOps

Are You Ready for Your DevOps Transformation?

You’re done with missed release deadlines, long release cycles and risky releases. If your objectives are continuous application delivery to achieve fast feedback loops and reduced waste, DevOps practices provide the means to reach them.

DevOps is all about agile transformation, which reaches beyond agile development into production to achieve continuous delivery. DevOps practices provide help for the necessary next step after agile development to leverage the full potential of agile and avoid massive post-delivery changes through the development teams, but before they are ready to go into production.

The challenge is to navigate that DevOps transformation—and make it happen faster and at less risk. The speed and direction of that transformation depends on individual circumstances—for example, the type of technology you have deployed, the shape of your organization structure and processes, and what your overriding business and IT requirements are.

Beginning the Transformation Journey

Only once you have assessed your organization’s current DevOps maturity and orientation can you begin to scale your DevOps implementation—and move faster on the transformative journey toward continuous delivery. In other words, to know where you’re going, you need to know where you are now.

By measuring your status across each of these dimensions on a scale of Level 0 and Level 4 (see diagram), you can benchmark where you are today and derive recommendations and measures for future improvements.

Culture and Strategy: DevOps requires a strong vision and strategy and its success will depend on the awareness, knowledge, skills and motivation of your employees. This pillar addresses the effectiveness and alignment of your awareness-building and enablement programs as well as your incentivation system with regard to agility in all involved units, dev and ops. It also includes a snapshot of the sentiment and motivation of people to make such a change reality.

Automation: This pillar addresses the maturity of your organization in terms of IT automation as an important prerequisite for continuous delivery. Both the application architecture and the DevOps automation tool chain are assessed. Relevant automation capabilities in application configuration, provisioning, deployment, test, infrastructure and application monitoring are included in the assessment. The maturity is assessed across the tree layers infrastructure, platform and application, and by technology stack—for example, your SAP platform, .NET or Java stacks—and then combined into a single level.

Structure and Processes: The current organizational structure and methodologies and processes in use within all involved units are assessed with regard to their effectiveness for continuous delivery. This focuses on their agile fit and maturity. Governance and how agile teams and processes are embedded into the broader organization are part of the assessment scope as well.

Collaboration and Sharing: Collaboration and sharing between development, operations, infrastructure and middleware teams are crucial to accelerate the delivery process and make it leaner. The assessment looks at particular sharing vs. redundancy of tools (e.g., tools used for deployment), information (e.g., the status of a package in the delivery pipeline), processes (e.g., an ITIL release process and a development release process) and functions (e.g., a release engineer in development and a deployment expert in production).

Now you have the facts at your fingertips. The DevOps Maturity Assessment Service presents all of this as documented findings, to include a series of recommendations on how you can scale and mature your DevOps activity.

January 28, 2016
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.
January 14, 2016
What is expected of software developers vs QA testers during development?

“What is expected of software developers vs QA testers during development?”

Michael Oubre – Agile evangelist, practitioner and trainer, and Marc Hornbeek – DevOps evangelist and thought leader, share their views on popular questions regarding Agile and DevOps from their respective viewpoints.

Michael: The thing we do in agile is to train the team to understand that they equally share the responsibility for all aspects of delivering completed, functioning code to customers, and that we deliberately try not to make any differentiation between the various skills possessed by the members of the team. As a result, we try to remove any reference to QA or PV or any other term that has the connotation of the old way of doing things – testing is done as part of the development and not a process that happens when everything is coded. Testing in an agile model is ALSO done incrementally, in-line with the development, which is what makes CI absolutely critical. Everyone on the team tests, it’s just that there are some tests, just like some coding activities, that require specialized, senior skills, so there are people who contribute to those testing activities more than others.

Marc: In best practice DevOps environments everyone on the team is responsible for quality. The specific task responsibilities for continuous testing may be allocated in different ways depending on the organization’s preferences but developers take at least equal responsibility for test results as QA team members. Whether the developer or tester is responsible to design and create tests for a code change is a team decision. For example a developer may take responsibility for white box tests because of familiarity with the code but a tester may be the one that creates functional test cases, and together the tester and developer may review all test cases and work together to ensure all tests and code changes reach a successful result within the development “pre-flight” environment prior to integration into the DevOps pipeline. In any case, no matter the allocation of test tasks, the code changes are not deemed ready for integration until the tests are ready and working with the code changes. Both the code and the tests for the code are submitted together into the DevOps integration branch. If this is not done there is risk that the code changes will not pass CI testing after integration, resulting in rollbacks and process waste.

Bottom line is, both Agile and DevOps do not prescribe a specific division of test task responsibilities for developers and testers. Both are equally responsible to ensure tests are conducted and successful results are achieved.

At Spirent we think Agile and DevOps work together to help teams develop and deliver quality software efficiently. More information about Spirent’s views can be found at the following links :
Does Agile Need continuous testing?
Spirent.com/solutions/devops

What do you think of these views and do you have other views?

Michael Oubre
is an expert in Agile practice, transformation and management and has spent more than 10 years as a practitioner, coach, trainer and evangelist. His long and eventful tech career has given him practical experience and insight into every aspect of building, deploying, supporting and managing software, systems and networks. https://www.linkedin.com/in/michaeloubre

November 19, 2015
The One Where All the Deployments Stall

In the first episode of the DevOps story, DChip CEO Phoebe gave Chandler an ultimatum to move out of AWS into their datacenter on OpenStack. Does Chandler succeed? Read on to find out…

Fast forward two weeks since that fateful night. Chandler is preparing for yet another leadership call. It’s deja vu, with the same story all over again. Only this time he knew the problems all too well. So he sat bleary-eyed and prepared what to say.

Time to face the music

The meeting involved the usual suspects. Phoebe, Monica dialed in from the US along with the sales and marketing VPs and Janice the VP of Finance.

Strangely, or maybe it was the late hour of the night, Chandler felt calm as he spoke:

“I want to bring everyone up to speed on the progress to shut down AWS and move to OpenStack in our datacenter. We have bad news. Enogo engineers were not able to migrate workloads to OpenStack smoothly. The problem is such that they have not managed to release a single update, and the release schedule has started to slip.”

Both Rachel and Joey eyed him sharply. He wasn’t going to back down from the truth now, so he ventured: “Engineering sprints are delayed because of this. The real problem is the OpenStack environment. It’s not mature. Most IT operations engineers are still learning to configure it, and there are many environment issues. I understand, everyone is going to hit panic mode. Which is why, I say, we keep AWS Cloud to return to business as usual.”

Soon as Chandler finished, the finger-pointing began.

“Enogo engineers used CloudFormation templates in AWS for dev/test/staging deployments. Those templates, however, don’t work in OpenStack because Heat is not set up properly,” Rachel said. Adding, “We sent the templates to the Ops team, but they never got back to us.”

“Well, when the templates are not written correctly by the developers,” countered Monica, who headed the OpenStack implementation, “we have to rewrite them from scratch in Heat. That’s not going to happen overnight, is it?”

All the while, Phoebe, who’d hardly said a word knew that Chandler was right. The 3-month transition plan to OpenStack was too aggressive and just not practical. If more and more developers choose AWS cloud, why not join forces if we are to help them succeed?

As a leader, you have to know when you’re wrong and correct course. So she did. “Chandler is right. We should go back to AWS to avoid schedule slippages and get the release back on track. I will discuss a longer term plan with Chandler.”

We need a solution

After everyone except Chandler had dropped off the video call, Phoebe said: “Look, we f*****d up. We can’t go through another f***k up and face this kind of deployment shutdown. We need a solution and fast. What do you say Chandler?

“I can’t agree more. To minimize business risks and integrate both company systems, we need a hybrid solution that supports deploying to both AWS and OpenStack clouds. It’s not enough to simply solve for the template problem of today. It should scale for future projects. We need a solution that offers a single point of management for both clouds. The Enogo team should be able to deploy with the same speed and ease of AWS in OpenStack and not rely on IT Ops to hand-hold them.

“Bingo,” said Phoebe at last smiling.

The next morning as Chandler stirred his coffee trying to awaken his still asleep brain, he read this email from Rachel:
“Hey Chandler, a couple of engineers have already written a bunch of scripts to automate deployments in AWS. I say, we devote a few more engineers and build an org-wide solution that will enable us to build and deploy in both clouds. What do you think?”

How timely, thought Chandler. So Rachel, the Enogo engineering manager wants to build the solution in-house with her team of engineers. She wants five engineers and six months to do it. This project will no doubt widen her impact and visibility in the company. Good for her!

Chandler sent a brief, “Why don’t we discuss in person tomorrow,” reply. In walked Rachel the following afternoon. The minute she saw Chandler’s face, her enthusiasm took a dive. He doesn’t look amused, she thought. His steely gaze sent a chill up her spine.

Wait to see what happens in the next installment of the DevOps story coming soon from ElasticBox.

March 14, 2015
Tuning in to the real pain of customers

In my product management and marketing experience, I discovered that I carry a deep bias about our product capabilities and why it’s special — before a launch. On a whiteboard, in a spec, or in a usability lab, our product can and will change the world. Post-launch, when customers get their hands on our product, magical things happen. Intended use cases become irrelevant. Intended benefits change. Intended value changes.

Over the past weeks, I’ve had the privilege of talking to many of our customers and prospects. They educated and helped me reframe the value we deliver to our customers.

Real pain

Much has been written about the DevOps revolution, driven by applications moving to the cloud, mobile computing, and the business need to compete. The journey to an agile build-test-release cycle is real, and it’s hard. It’s hard for customers who are cloud-born, and it’s even harder for traditional operations and development teams. Listening to our enterprise customers who are several years into their transformation, I heard a lot about the explosion of technologies and the cultural challenge. The pain of the change is more excruciating than I realized. One large customer told me that two years ago, he (VP of Cloud Operations) and his team couldn’t stand to be in the same room as the development team. Today, they’re collaborating to the point where they now sit together.

Demanding developers

Secondly, developers are more demanding. Again, it seems obvious, but hearing firsthand how hard it is to empower developers brings it home. Developers want and require more agile build, release and deployment capabilities, but they don’t want to be infrastructure experts. Enterprises are beginning to offer self-service to their private and public clouds so that developers can have autonomous access to environments and resources. A leading biotech customer told me that he can’t dictate policies and processes anymore, that he needs the researchers and scientists to adopt and embrace what the DevOps team is providing. Finding the appropriate balance between freedom and speed along with control is a common challenge across the board for our customers.

Delivering value

At ElasticBox, we talk a lot about the technology and cultural shift in enterprise DevOps teams, and how we can enable greater collaboration by being at the nexus of the transformation. That is what we ultimately deliver to our customers: a new way to deliver applications to the cloud that’s better, faster and more efficient.

It’s a big promise, and we’re excited to fulfill it. Today, we deliver the foundational tools for self-service provisioning, service catalogs and continuous integration and delivery — wrapped with a flexible box architecture that’s reusable and agnostic to the underlying infrastructure and deployment tools. We approach the problem from a developer mindset to drive speed and autonomy, and at the same time, provide the policies and reporting to ensure scale. We’re hungry to continue learning from you, so check us out and let us know how we can help.

March 3, 2015
The One Where All Hell Breaks Loose
Don’t you love a good story? This one is a DevOps story in a fictional enterprise. It’s the kind of story you’ve seen replayed countless times in large organizations. So settle in for a read.

The backstory

DChip Tech is a semiconductor company. They’re in the business of making chips for wearable computing since acquiring Enogo, a startup in France for simulated testing in wearable technology.

Three months into the acquisition on a late Sunday night in France, the VP of Operations at Enogo considers his late evening ahead.

Chandler is not a happy man despite his recent appointment as the VP of Operations. How can he be? How can a 40-person company in France give him so many sleepless nights? And tonight is no exception.

DChip’s strategic momentum in the last months had everything to do with it. To leverage the cream of the crop engineering talent in wearable tech, DChip, the San Francisco Bay area chip giant invested in Enogo.
- Now DChip wants Enogo systems fully integrated into its OpenStack datacenter to reduce infrastructure costs.
- Although Enogo hosts on AWS, DChip doesn’t want to integrate AWS Europe into the corporate network. They want to keep the intellectual property in the US.
- It falls on Chandler’s lap to integrate the systems of both the companies and reorganize IT, to speed up DChip releases from once every six months to the weekly push like at Enogo. Imagine all that.
Tall order, he thinks wryly, gulping down another cup of coffee to keep him awake for the Monday morning US time leadership meeting.

Where all the action happens

He dials into the video conference warily, his head already starting to throb. First to appear on the screen, Phoebe, the CIO is looking none too happy either. Soon all the division heads appear on separate screens including the engineering and QA heads from Enogo.

Dismissing the usual small talk, Phoebe launches right to the point. We have a firm deadline to move out of AWS cloud in three months. Yet, where do we stand now? Can someone explain why the delay in integrating the systems of both companies? Do you know how much this is slowing down our go-to-market strategy?

Monica, the Chief Architect in charge of the Datacenter OpenStack cluster, says, “We’d love Enogo to move to OpenStack today. But it’s not fully stable.”

As if to emphasize the point, Rachel the engineering manager whose team is building the wearable emulation test software adds, “We can’t wait for the OpenStack cluster to work. Our engineers need test environments like yesterday. That’s why using AWS makes sense.”

The marketing and sales VPs quietly watch as everyone joins in the blame game.

Not to be left out, Joey the Enogo QA Manager complains that he can’t deploy the image that contains the emulation software because OpenStack is corrupting it. “All the more reason to support AWS,” he quips.

The ultimatum

I’ve heard enough; Phoebe bellows over the din of the meeting. She turns slowly to glare at Chandler through the video camera. “Chandler, do you care to explain why we have an unforeseen $100,000 dollar expense this month? I want an explanation.”

“It’s a case of a simple, human error; it can happen to anyone Phoebe,” Chandler tried calmly to explain. “One of the devs launched instances and forgot about it until we got the bill.”

“Yea” piped up Janice, the VP of Finance. You’ve been paying the AWS bills out of your credit card, Chandler, and then billing the company after the fact,” she so helpfully points out.

Chandler stands dumbfounded as Phoebe’s final words struck his heart: “I told you to shut down operations on AWS. I want to move to our datacenter on OpenStack. No more bills from AWS Chandler, you hear me?”

Her words rang late into the night and the next day.

To be continued…

(What do you think will happen next? Watch this space for our next episode of the DevOps story. Any resemblance to these characters or events in real life is purely coincidental.)
February 9, 2015
Evolution Not Revolution – DevOps in the Wild
Ever heard these questions:
- What is DevOps?
- How do I hire a DevOps Engineer?
- Should we have a Director of DevOps?
- Am I doing DevOps?
- Why is DevOps failing in my organization?
More and more frequently, I run into engineers, managers and business leaders describing failures in their organization due to “DevOps.”

Oddly, digging a little deeper, I find that most of these cases are simply failure by substitution. The Operations team was failing, so they rebranded it DevOps. Alas, buzzword compliance was unable to change the trajectory of the team and the buzzword was blamed.

DevOps today is–still–an ill-defined set of practices closely associated with automation and operations. If you accept this as fact, then DevOps can neither fail or succeed. If we want to measure the success of the DevOps movement in an organization, then we need a definition that leads to accountability.

A Definition for DevOps

The DevOps movement, unlike Agile, lacks a manifesto. To fill that gap, I assert that DevOps is a philosophy and that its base definition is:

DevOps is the way in which a technology organization embeds itself in a business to the benefit of that business.

The business in question need not be a technology company such at Docker or IBM. Indeed, all companies today are technology companies whether they like it or not. (1)

In this and future articles I will write about philosophy, models and implementation. In short, a philosophy is what I reason from to create models of behavior. Models inform the actions taken in an implementation. Implementation without philosophy leads to failure. Jingoistic adherence to philosophy without accounting for new technology leads to failure. Balance must be acheived.

As an example of this sort of failure, take a lesson from project management. Many shops adopt Jira because it can do anything. Since the tool can do anything, that means their workflow is capable of anything! Problem solved, QED. We all know tools are not process. When we look at our own track records of instituting change. too often the change stemmed from tool choice, not critical thinking about what was to be accomplished.

Tools should reflect the philosophy they are implemented to support. Without that philosophy tools will fail. The more complex the problem or tool, the more spectacular the failure. In this example, Jira did not fail, leadership failed. Specifically the thought leaders entrusted with workflow management.

Are you Doing IT DevOps Style

DevOps is about evolution. If you are doing IT DevOps style, then you are asking questions like:
- What should we change next?
- How do we create a sandbox to measure the impact of the change?
- How do we create demand for the change once vetted?
- Who do we need to be patient zero?
- What cultural paradigms are we shifting and how do we ease this for teams?
While automate-all-the-things is often associated with the term DevOps, automation without cultural shift will result in broader failure, rather than success. Like any technology problem, at its core DevOps models account for their impact on people because businesses are composed primarily of people.

Future Articles

Over the course of the next few months. I will relate my experiences at several companies. Articles will describe:
- What we changed.
- Why we changed what we did.
- What cultural issues we faced.
- What technologies we used and why.
I hope you will join me to learn how the practice of DevOps as a philosophy can lead to millions of dollars on the bottom line, happy bosses, fluffy bunnies and rainbows. If your lucky, you might even become a unicorn, though my own horn has yet to sprout.

The first case study will describe a failing company with three months capital. An amazing team. Some amazing mistakes and, ultimately, some amazing success. Technology decisions driven by the needs of a sales team. Automation driven by a business model. A successful acquisition.

References

(1) The Phoenix Project – Gene Kim, Kevin Behr, George Spafford
(2) Good to Great – Jim Collins

About the Author/Boyd E Hemphill

Boyd E Hemphill is Director of Evangelism at StackEngine (link). , an enterprise grade, Docker operations management software company. DevOps raconteur and organizer of community events in Austin, find him on Twitter or LinkedIn.
February 4, 2015
A DevOps Metamorphosis Echoes Through Reverb.com, Part One

“Reverb.com is an e-commerce platform that connects musicians, enabling them to buy and sell used gear and instruments,” says Adam Enger, Senior Infrastructure Engineer, Reverb.com. As an ecommerce site, it is critical to Reverb.com that its workflows such as checkout, offers to purchase, and messaging work in tandem with its selling workflows, which include creating new listings and managing orders.

The Reverb.com team also develops a free, comprehensive online price guide and a complex in-house content and curation system that allows them to hand pick and recommend the best gear for their customers. In the Reverb.com marketplace, all software components must run smoothly for customers to have the optimum research, buying, and selling experience when conducting trade on musical equipment.

To create those components, Reverb.com developers code primarily in Ruby on Rails on Macs. The etailer runs Linux in its production environment. “Our backend stack includes PostgreSQL for our database, ElasticSearch powering our search engine, and Redis for queueing and key value storage,” says Enger.

Not So Good, Old-Time Deployment

Prior to DevOps approaches, Reverb.com deployed code from individual user workstations. “For configuration changes to our infrastructure we had to use SSH to connect into production. All while our fingers were crossed, of course,” says Enger. This loose-knit deployment process presented Reverb.com with some obvious challenges.

“If a deploy failed due to an engineer being on a bad internet connection, we could potentially have had two updated hosts while three were still running an older version of code,” says Enger. This was especially problematic because these deployments often included database migrations.

There was also no real way to know when a deployment failed or who started the deployment. “The process was devoid of any deployment log records, so errors and anomalies were harder to spot when the deployment was swallowed in the developer’s terminal,” says Enger.

These risks made it possible for Reverb.com to face an even bigger risk: a lapse in faith on the part of its customers. Reverb.com’s reputation as a marketplace hinges on the perception of trust among its customers. Every aspect of the organization generates trust. From how Reverb.com interacts with customers as people, to how its systems present to users, the firm wants to exude confidence. “If we experience outages and slow performance, we may erode our trust with our audience,” says Enger.

Goals For DevOps

Reverb.com had many goals for DevOps in the hope that it would meet their challenges to fast, scalable, reliable delivery of code and configuration changes. Reverb.com needed to know when a change was going out. The firm needed to be able to deploy at a moment’s notice.

“All processes must be behind the click of a button or an SCM post/pre trigger,” says Enger. All Reverb.com deploys must be logged and graphed. Scaling the team and the business should become easier if the teams have quick, repeatable processes that allow them to push new features and bug fixes quickly onto the new DevOps platform. This should allow for a scalable and dynamic workflow for the Reverb.com marketplace so it can be nimble, adapting to the users’ needs as they arise.

Reverb.com’s Reasoning: An Automation Proclamation

Reverb.com made its move to DevOps on the basis that the more the automation, the less the likelihood of human error. From that, Reverb.com development staff should create fewer issues for its customer base as consumers browse the website, make purchases, and sell hardware.

“It’s extremely important to look at root causes here: if we only treat the symptoms every time the site slows or goes down, we will be playing Whac-a-Mole forever,” says Enger. By using the DevOps mindset, initiating repeatable and automated deploys, and measuring performance and application metrics in rea-time, Reverb.com developers should be able to trace when something was released, how it affected users, and whether customers are having a poor experience as a result.

In the hopes that this would equip them to quickly pinpoint issues and fix root causes, the band of coders at Reverb.com set out on the road to DevOps, fired off its first continuous delivery power chord, and awaited feedback.

Conclusion: Cliffhanger

Tune in next time when devopsy.kinsta.cloud reveals how Reverb.com adopted DevOps and used it to meet these development challenges and goals in the exciting conclusion of “A DevOps Metamorphosis Echoes Through Reverb.com”.

January 28, 2015