devopsy.kinsta.cloud

Tag: devops

DevOps by the Book in 2017: Where we Really Stand

Now that the year-end prediction season is over, it’s time to focus squarely on the actual here and now—where the DevOps movement actually stands at the start of 2017.

As we’ll need to wait another six months or so for the annual State of DevOps Report to emerge from the good folks over at DORA and IT Revolution, which forces us to take stock of the situation using other resources. In this case, I’ll point to the recently released book, “DevOps for Digital Leaders,” authored by my colleague Aruna Ravichandran along with co-authors Kieran Taylor and Peter Waterhouse.

Register today for the upcoming webcast, “Chart a Winning Course: DevOps for Digital Leaders,” and enter the chance to win a free signed copy of the book [U.S. only].

Why should you value this book over any of the other DevOps-related titles inundating the technology literature scene, in particular those issued by (gasp!) technology vendors? I’d cite two very specific reasons: real-world metrics and use cases.

I often preview any comments I make in cross-functional meetings with the phrase “shameless marketing.” That is because I work in marketing. For 12-plus years prior and sometimes in between marketing gigs I’ve served as a journalist, wherein my job was to attempt to be as objective as possible. Today, I work for a vendor that would really like to sell you stuff.

That said, this current career path does not preclude me from being able to see beyond my own not-so-secret agenda. While many onlookers understandably groan and roll their eyes at the manner in which DevOps has been co-opted by marketers as a means to advance products, this doesn’t mean we’re all full of it.

Like myself, working at CA—in particular, leading marketing efforts that span a huge array of strategic technologies actively being leveraged by global enterprises to attack various elements of DevOps—has given Aruna and her partners tremendous insight into where many people stand in terms of maturity.

To that end, this book is written around some fantastic stories about how some of these organizations are refining best practices and measuring real success in domains including continuous testing, release automation and shift-left monitoring. IMHO, these are some of the hottest areas of DevOps being advanced as we speak.

In addition to these use cases and related practices, the book takes an up-close look at critical aspects of the DevOps build, test, deploy and manage stages, along with key processes related to tuning and continuous improvement. And it even goes so far as to talk about essential DevOps tooling. I hope people are ready to acknowledge that beyond culture and leadership, automation absolutely plays a significant role in all of this.

Specific to metrics, one of the areas where the State of DevOps peeps attempted to break new ground in the 2016 report, there’s a lot to appreciate. The book takes a close look at how these same organizations are attempting to tie DevOps-driven change directly to ROI, including the all-important customer experience.

Worth noting, in the coming days we’ll also see the release of a new report from Coleman Parkes that charts numerous KPIs being used to this same end, so stay tuned.

So there you have it, the marketer has officially hijacked this blog space to do little more than market a book about DevOps written by marketers. But, the truth is that’s not all.

If you really want to hear the best parts of this story, sign up for the upcoming devopsy.kinsta.cloud webcast, “Chart a Winning Course: DevOps for Digital Leaders,” in which Aruna and Alan Shimel will discuss the high points, with an emphasis on fielding questions from the audience live Q&A style.

If you don’t have time to read the book—or, better yet, you want a preview to ensure that what I’ve written here is true—post up and ask your own questions. We’ll also be conducting live polls about DevOps maturity, audience use cases and the leading types of DevOps metrics.

It’s worth noting that all proceeds from the print edition will go to Foundation for Excellence, which provides STEM scholarships to children in India. Order your own copy today (or download it for free).

— Matt Hines

January 12, 2017
Automation: Achieving Faster Rollouts with Better Accuracy

A changing landscape requires new processes

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

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

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

In-Steps DevOps

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

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

Finding the Balance Between Speed and Accuracy

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

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

Breaking Constraints Through Automation

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

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

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

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

About the Author / Mehul Amin

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

January 11, 2017
Time, Training: How to Implement DevOps Effectively

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

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

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

Training Your People

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

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

Push from the Top

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

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

Test the System

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

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

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

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

About the Author / Francis Miers

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

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

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

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

For more reflections and predictions, watch the full episode:

About the Author/Anders Wallgren

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

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

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

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

The next phase of DevOps will focus on security

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

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

Containerization will go mainstream

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

DevOps will extend into pay-as-you-go

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

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

DevOps will become pervasive across the enterprise

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

Watching the Shift

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

About the Author / Tan Moorthy

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

January 9, 2017
Best DevOps Practices for 2017

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

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

Make paying off debt a priority

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

Set ambitious goals, but don’t sweat the details

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

Don’t leap, but get moving

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

Identify the ‘credit hawks’ and neutralize them

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

Plan for failure, success through learning

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

Promise to break the rules

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

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

About the Author / Adam Bowen

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

January 6, 2017
Customer Demands Outpacing Business Requirements

As more organizations adopt agile and DevOps, many recognize quickly that the related gains are significant but further business efficiencies can be realized.

IT and the business now are working closer than ever. No longer is the business throwing requirements over the wall into the IT “sausage factory”—they’re now an integral part of the entire process. IT has finally transitioned into a profit center.

In the application economy, it’s not the layout or cleanliness of your brick and mortar store nor the friendliness of a customer service representative that makes your business successful. It’s the application’s user experience.

As a result, the gains we’re seeing must be optimized continuously. One of the biggest challenges we face today lies in how we get business requirements translated into IT output, at the speed of business.

In the old days, it was easy to move your best-selling, highest margin products into the ideal location or open another checkout when the lines got too long. With today’s virtual stores, the question becomes, How can we quickly pivot to tend to our real-time customer needs and shareholder expectations?

We must be able to deliver software faster, and to do that, we need to marry our strategy to execution and delivery. We must optimize across the entire business to create true agility that paves the way for reactive and proactive acceleration.

Case in point: If you optimize execution but not delivery, you’ll be creating software that cannot realize value at the pace of development. In reverse: If you optimize delivery but develop software slowly and poorly, your efficient delivery process will merely sit waiting—or worse yet, deliver poor quality software quickly.

As a result, we must optimize all three of these areas while working in conjunction, overlapping and providing constant feedback and properly timing the impact of revenue and potential risk to customer experience.

Unsurprisingly, to support all of this, we’re also seeing broader adoption of an end-to-end solution stack that supports acceleration of process from ideation through outcome. Let me walk you through this scenario:

Your business is managing your strategy through the lens of its portfolio. As changes are set in motion at the highest levels, that data must be tracked—how much it costs to implement new functionality, how much time it should take and what ROI looks like—along with constant reviews to inform ongoing decision making.

Your portfolio decisions are then loaded and tracked systematically at the project level, with resources assigned systematically to deliver the designed functionality through epics and user stories. Related data must also be made available in real time to be viewed at the program, project, epic or user story level, providing complete visibility from the level of developers all the way up to the board of directors.

Simultaneously, your user stories must be imported into a system that turns them into test cases and test automation assets, then builds the test data synthetically to validate each test case. Once the data is generated, it’s imported into your service virtualization system, where application behavioral virtualization eliminates the need for constrained and non-existing back-end systems, simulating an end-to-end environment for any application that is being tested. This also should update your virtual services automatically with the data required for the test cases and any planned test automation.

Let’s pause and review what we just did.

We’re now managing our new functionality items across portfolio, program, project, user story and resource levels, all in real time. We’ve automatically created our test cases, test automation, test data and virtual services, all from the epics and user stories.

So what have we done? We’ve provided the visibility and insight necessary to make business decisions in real time and track progress. We’ve also also minimized the need for test-case designers (or the business analysts that create them), test automation engineers, test data engineers and the DBA support for test data, freeing these experts to focus on other activities.

Hopefully, we’ve achieved the desired result of massive reduction in resource allocation, acceleration of the entire software development life cycle, elimination of error-prone manual tasks and, most importantly, elimination of the ambiguity involved in translating actual requirements into test cases.

Finally, we’ve now got all the necessary elements—team execution, prioritization by value, connection of value to execution, a platform that provides a single source of the truth, communication, and metrics—that will allow you to focus on creating value for your customers, instead of simply creating process.

Transformation is difficult. Culture/environment eats process for breakfast. However, by focusing on changing your entire approach instead of merely recasting process and teams, you can truly change how you provide value to your customers and shareholders.

This is how we translate business requirements into innovative software at speed.

For added perspective on all things DevOps and Continuous Delivery, join my colleague Aruna Ravichandran for a live webcast highlighting the details of her new book “DevOps for Digital Leaders”—it’s sure to be an exciting discussion.

— Ron DeCanio

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

Haphazard Development

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

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

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

DevOps Transformation Solution

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

By standardizing, this customer has transformed its dev and ops teams, creating an agile, scalable environment that can drive the business forward. The company achieved the following specific results:
- Project delivery are now completed with 90 percent fewer delays. First customer-facing releases of projects now are usually delivered in less than half time.
- The usability of websites has increased significantly, resulting in more customer traffic, customers remaining longer on the sites and increased revenue opportunities.
About the Author/Michael Schmidt

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

We at Shippable recently approached some DevOps experts and asked them what they really think about continuous integration (CI) and continuous delivery (CD). The responses were just amazing, proving that CI/CD’s future is just bright and long in the software development process.

Perhaps this insight might be of help to organizations, regardless of whether they already practicing CI/CD or have yet to adopt it in their organization.

Sit back, relax and read these opinions from DevOps Experts:

1. Chris Nwamba

Chris Nwamba is a self-described code beast who works with scotch.io. “Continuous integration is simply ‘building big and shipping small,’” he said. “The developer or engineer is not expected to produce a complete result; the project is divided into milestones and he or she can produce the expected output for each milestone which is reviewed and pushed. Continuous delivery, on the other hand, involves delivering and deploying a tested and usable feature to the end user as soon as it is available from the engineer. No constraints such as milestones or daily reports are placed on the engineer; rather, the product is delivered when it is ready and tested within a reasonable amount of time.”

2. David Bernstein

David Bernstein is the author of “Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software.” He says, “I’ve written a lot about CI and CD. It’s one of the nine core practices in my new book. The first principle of the Agile Manifesto is, ‘Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.’ The practice of continuous delivery is the only way I know to achieve this principle and is at the very core of Agile software development.”

3. Tomohiro Iizuka

Tomohiro Iizuka is a full-stack web application developer. He says, “Continuous integration and delivery are still at the frontier of IT technology, like NoSQL. It will change the business style of freelance engineers. Businesses using cloud servers will especially change. However, there are some issues to solve in order to execute it. An IT system consists of some subsystems that affect how teams work together on development and management after the first release. If an engineer can provide a subsystem that’s comprehensive to end users, freelance engineers can have their own product and they can concentrate on maintaining their own product continuously. That will make use of cloud platforms more popular, and they can have opportunities to gain profit continuously in addition to development fees. Open-source products like Eclipse, Firefox, WordPress are some examples. However, in general, that is not done. I think that the platform for making independent software components is necessary for freelance engineers to make new businesses with continuous integration and delivery.”

4. Anubhava Srivastava

DevOps expert Anubhava Srivastava is a lead engineer-architect at AOL Inc. According to him, some of the advantages of CI and CD are: “DevOps and CI/CD give more power to developers. Developers have greater control over the application stack and require access to production servers. The exact same repeatable deployment process is used across different environments like dev, QA, staging and production. Everything is automated right after code is checked in. There’s fast and quick resolution time for emergencies. Due to code coverage reports being monitored and shared widely, developers are forced to write test cases for every line and every condition in the code. Due to stress on TDD, developers are producing higher-quality applications with significantly fewer bugs. It has definitely helped the organization, as they don’t need the same headcount for QA and Ops teams anymore.”

5. Erik Dietrich

Erik Dietrich is the founder and principal of DaedTech, LLC. He says, “In short, both of those [CI and CD] are practices that I endorse and help people move towards. On the whole, I’m a huge fan of automating the automatable to avoid mistakes and save time.”

6. Tom Zorde

Tom Zorde is an enterprise architect at Monadelphous. He says, “There is an inevitable need for CI, no doubt. But developers need to have autonomy to self-elect to skip a check-in if they don’t feel their code contribution is ready. This will reduce the wasted effort of dealing with failed integrations and keep developers focus in the zone.”

7. Ian Robertson

Ian Robertson is a product owner at River Island. He says, “I work in retail (fast fashion). While we do build core ranges to meet the seasons, it is our quick response to rapidly changing trends that generates the excitement that drives our brand values. An emerging style cue seen on the catwalks one Friday can be in our stores and online by the following weekend. Those same customers expecting the latest fashion will be interacting on our app and website, so we need to be as Agile in development and deployment as we are in apparel design and production to keep up with customer expectations. It’s not just the front end; our supply chain, logistics and merchandising systems need to be able to respond rapidly to real-world changes. Adopting CI and CD allows us to reduce the time to market, reduce risk, deliver better customer experiences and drive value for the business.”

8. The Folks at Browser Up

Browser Up is a performance and load testing tool. Folks there say, “Using CI and CD is a force multiplier that amplifies the speed at which software can be developed and delivered. To be effective, a CI and CD pipeline must include a robust test suite that include continual performance and functional testing.”

9. Georg von Sperling

Georg von Sperling is a practitioner, evangelist and general geek on software development methodologies, technology, patterns, systems, delivery practices and DevOps. He says, “CI and continuous deployment are very technical in nature and benefit the technical teams. They are crucial to address. They do not, however, define continuous delivery. CI could be defined as an early detection system at the code and build level. Early detection at those levels have been proven beneficial as these are types of bugs that are exponentially more costly to remediate at later stages. Continuous deployment is an ability to promote code technically down the pipe into production at velocity, allowing consumption faster. There are facets of continuous deployment that must be considered: rollback, A/B testing and metrics gathering. Many fail here very quickly. Continuous delivery (of which I am an avid advocate for) is a business subject; although, in software powered organizations and/or digital business models, it has a fairly large technical component. It is very difficult, if not impossible, to translate CI and continuous deployment into direct business benefits. Continuous delivery, however, is business metrics-driven and defensible at the CxO level to stakeholders and shareholders.”

10. Endi Sukaj

Endi Sukaj is a full-stack developer who specializes in back-end development. He’s currently a community team member at Slant.co. He says, “CI is a crucial part in the development and deployment process of projects of a certain size especially if two or more people are working on it. The most valuable resource is time, and a good CI service and implementation helps developers in saving as much time as possible by avoiding ‘integration hell’ and by running all unit tests in the same environment as in production.”

11. Jordi Mozcode

Jordi Mozcode is a software developer focused on .NET Core, MVC, TDD, SOLID, clean, software quality, best practices, secure coding and pentesting. He says, “In my professional experience, the adoption of continuous integration and continuous delivery improves three basic facts: quality, flexibility, and speed. Quality, because CI guarantees a much lower rate of development bugs and CD provides a robust and secure system throughout the development cycle. Flexibility, because at every step of the development cycle you have the control of continue to next step or going backward easily. Speed, because in an idyllic case with no development bugs the release can be deployed in production almost instantly.”

12. Dave Kerr

Dave Kerr is a software developer for everything from device drivers to full enterprise applications. He says, “If the org is building tech services or products, CI and CD are critical. Deployment doesn’t need to be continuous but the team needs to be confident that what they are building is shippable.”

13. Matt Kurleto

Matt Kurelto is a serial entrepreneur and CEO at Neoteric. He says, “I think it’s a necessity if you are thinking seriously about cloud services. I think that microservices architecture can only be well-leveraged with automated CI, CD and QA flow, and for me, this setup is a must if you want to take advantage of lean business and agile project management.”

14. Sean Handley

Sean Handley is the lead cloud applications engineer at DataCentred. He says, “CI and CD are things we practice on our tech team. They allow us to ship production changes many times per day in confidence. My view is that any software team not using CI and CD needs to seriously reconsider their methods!”

15. Manisha Sahasrabudhe

DevOps Expert Manisha Sahasrabudhe is the co-founder at CMO at Shippable. She says, “All companies are software companies today, and faster innovation is the key to winning against your competitors. Continuous integration and delivery are crucial in helping you accelerate your release cycles and innovate faster than anyone else. This will become especially important as microservices become ubiquitous and your application is composed of hundreds of services that need to be deployed, scaled and monitored independently. CI and CD automation is the only way to bring some method to the madness.”

We hope these DevOps Experts opinions are enough for you to figure out how important it is to adopt to CI/CD practices.

— TeamShippable

January 4, 2017
Top Reasons to Use Node.js

When considering the architecture of a new web app, it might be a good idea to include Node.js in the discussion as a key part of that architecture. Node.js could provide you with additional speed, can be used on numerous platforms and has an active community from which to get modules and other assistance.

What is Node.js?

Node.js is a server-side platform developed by Ryan Dahl in 2009. It was built on Chrome’s V8 JavaScript engine and designed with a non-blocking, event-driven I/O. It is also cross-platform, able to be run on Windows, Linux and OS X. Its non-blocking I/O is due to its use of asynchronous functionality, which keeps the server from waiting on data to be returned before being able to move on to other tasks.

Why Use It?

Given the architecture of Node.js, a number of advantages are provided both to developers and the resulting apps they develop. A few of these advantages include speed, programming language consistency, real-time apps developed easily and a large number of modules/packages for developers to use while creating new apps.

Speed

Node.js offers speed advantages in many cases. First, it uses the Google V8 engine, which is optimized for JavaScript speed. Also, its use of non-blocking asynchronous behavior can ease the time it takes for users to see actions as complete, since things can be going on in the background while the user moves on to other tasks.

One Language

JavaScript is listed as the most popular programming language. Source: Thenewstack

Using Node.js, front-end and back-end code can both be in JavaScript, so your developers don’t have to transition between languages as they move through the stack. Some architectures, such as the MEAN stack (MongoDB, Express.js, Angular.js, Node.js), are designed around this principle. In this case, the stack uses JavaScript for Express, Angular and Node. MongoDB uses BSON for database queries, which uses the same syntax as JSON (JavaScript Object Notation).

Seeing full-stack developer as the largest occupation and JavaScript as the top language among both back-end and front-end aligns with what we’ve been seeing in overall JavaScript adoption.

Source: Mikeal Rogers, Node,js Foundation Community Manager

For developers, this can help both with moving across the stack during development as well as help communication among developers, as they will be referencing the same language (JavaScript) while discussing programming decisions.

Real-Time Apps

Node.js is a great platform for creating real-time apps. With a module such as Sockiet.io, you can create real-time chats, games and more. Along with its non-blocking asynchronous architecture, real-time apps can be developed with plenty of speed and responsiveness.

Modules

The Node Package Manager (NPM) makes it easy to install packages that others have developed to perform any number of tasks. This helps to encourage code-sharing among developers and to reduce the amount of custom development that has to be done when one or more packages can take care of that coding for you.

Notable Examples

Some notable examples of Node.js use are Paypal and Uber, showing that it can, indeed, be useful for large projects.

Paypal

Node.js and an all Javascript development stack helped PayPal bring efficiencies in engineering and helped rethink and reboot product, design and operational thinking.

Source: Sameera Rao, Paypal Sr. Business Products Engineering Manager

Back in 2012, Paypal had a single app running all things, including UI, API and more. This included a lot of duplicated code that was copied and pasted from one app to another to make apps for different locations.

Using Node.js, the company was able to modularize and clean up its code and processes, which in turn sped the development of apps it needed at any given time.

According to Paypal’s engineering team, they were able to build the Node.js app with 33 percent fewer lines of code and 40 percent fewer files, and were able to build it twice as fast and with fewer people than before. Certainly, Node.js proved to be advantageous to their development.

Uber

Uber used Node.js from the beginning, and its distributed system was a perfect fit, since a lot of network requests are made. The non-blocking asynchronous I/O used by Node.js helped to ensure those requests could be made and handled quickly to provide the best service possible.

Conclusion

The benefits of Node.js have been proven. It helps speed development, can be used on numerous platforms and has an active community from which to get modules and other assistance. Include Node.js in your future conversations about website architecture.

— Brian Wheeler

January 4, 2017