devopsy.kinsta.cloud

Tag: devops

What to Expect from DevOps Enterprise Summit San Francisco 2016
Many have asked me what I’m looking forward to at DevOps Enterprise Summit 2016 in San Francisco—it is the third year of our conference, and I think it will be our best conference yet! Here are three of the things I’m looking forward to most:

Where Are They Now?

First off, we will have seven speakers back to present for the third time at the conference. Having this pattern of repeat speakers is a bit unusual for a conference, but I love that we’re following these leaders on their continuing journey. For me, it’s almost as if we have front row seats of an unfolding documentary of the ongoing transformations that they are helping drive in their large, complex organization.

Why do I think this is important? My belief is that in the DevOps Enterprise community, many of us are on a common journey, increasingly being asked to help elevate the state of the practice for the entire technology organization, often involving thousands of engineers. To see the journey unfolding for other pioneering leaders is often a glimpse into our own future.

The third-time speakers include:

Heather Mickman from Target,

Scott Prugh and Erica Morrison from CSG,

Tapabrata Pal from Capital One,

Carmen DeArdo and his colleagues Jim Grafmeyer and Cindy Payne from Nationwide Insurance,

Terri Potts from Raytheon,

Courtney Kissler in her new role at Starbucks, and

Jason Cox, who is giving the closing keynote about the DevOps journey at Disney. (So stick around!)

Each of these leaders will recap on their DevOps journey so far, whether and how their roles have changed, the new challenges that have emerged since last year, and what they’ve done to overcome those challenges.

We’ll also be hearing from four people who have had a tremendous influence on the entire DevOps community: John Allspaw, CTO at Etsy; Mark Imbriaco, who led the Ops organizations at 37signals, Heroku, GitHub, LivingSocial and DigitalOcean; Adrian Cockcroft, who led the migration of Netflix into the public clouds; and Michael Nygard, author of the seminal book “Release It!”

Transformations from Different Industry Verticals

We always want to hear about DevOps transformations at all stages of the journey—I’m particularly looking forward to three of them that that are outstanding on their own merits, but are also interesting because of the industry they operate in: airline, hospitality and insurance. These are three industry verticals that we don’t typically associate with DevOps.

Susanna Brown and Ben Chan will talk about how DevOps is changing how American Airlines works (and doing it in the middle of its merger and integration with US Airways), Matt O’Keefe will talk about speed becoming the prime directive at Hyatt Hotels and Resorts, and Opal Perry will talk about her efforts to transform culture at Allstate Insurance (which, like Nationwide Insurance, operates in an industry famous for its centuries-old, risk-averse traditions and decision-making styles).

I’m also excited about another conference first for us, which is the joint presentation from Suzette Johnson and Robin Yemen, from Northrop Grumman and Lockheed Martin, respectively. I met Johnson at an Agile conference for the Federal Government community, and I was so inspired by the work that they’ve done within their firms and the broader community at large to improve outcomes for federal programs—both civilian and military.

New Session Format: DevOps Workshops

As adult learners—and this is especially true for leaders—we tend to learn more effectively from observation, experimentation and group exercises and group learning, as opposed to didactic lectures and descriptions of theory.

I’ve observed that the DevOps Enterprise community is truly a group of people who are helping each other. To help further enable the spontaneous and serendipitous interactions that make great communities great, we are adding a set of sessions called DevOps Workshops.

These are 60-minute sessions that run alongside the conference talks, and each workshop will focus on one of the community’s top problem areas:
- How can we better lead change in our organizations?
- What are the modern architectural and technical practices that every leader in our organization needs to know?
- How do we design our organization to best enable DevOps outcomes?
- What are ways that we can more effectively bridge the information security and compliance gap?
Each of these workshops will have a 10-minute introduction, which will be followed by 45 minutes of small-group discussions. And to help ensure that each small group achieves its learning objective, as well as to ensure open and healthy dialogue, we have decided to have trained facilitators use the Lean Coffee format.

Lean Coffee helps achieve this through a democratic selection of topics and rigorously enforced time-boxing of each topic. I’ve always been amazed at how effective this technique is at creating good outcomes.

(Why Lean Coffee? In my personal experience, all it takes is a bad facilitator or one person who loves hearing themselves talk to ruin the small-group session for everyone. I can’t think of a better mechanism than Lean Coffee to neutralize these risks.)

In addition to the amazing lineup of repeat speakers, expert talks, and new stories, my hope is that these DevOps Workshops will be of tremendous value and create fantastic learning and networking opportunities for all attendees. The collaboration and relationships that result from each of the DevOps Enterprise Summits never ceases to amaze me, so we’d like to give attendees a variety of opportunities to engage with our speakers and with each other throughout all three days.

I’m looking forward to the best DevOps Enterprise Summit ever! I hope to see you there!

— Gene Kim
October 13, 2016
DataOps: Time to Bring DevOps Ideas to Big Data

What can data scientists learn from DevOps? A lot, actually. By applying DevOps principles to the world of big data, you get DataOps, which streamlines data analytics.

If you’re reading this site, you’re probably already familiar with DevOps. The DevOps philosophy emphasizes continuous collaboration between software developers (the “dev” people) and system admins (the operations, or “ops,” folks)—as well as everyone in between, such as software testers.

It’s possible to apply similar ideas to the world of big data and data analytics. There, as in the world of software development and delivery, different teams traditionally have worked in isolation from one another. Those teams include storage admins, who keep data storage systems running; data analysts, who write and execute programs for interpreting large volumes of data; data quality specialists, who ensure data consistency; and data security teams, which protect data from attackers.

As DevOps professionals know, keeping different teams isolated from one another is not efficient. It limits collaboration and maximizes confusion when problems occur.

The data world, therefore, has much to gain by ending this isolation between teams and adopting a DataOps workflow. This will keep data operations flowing smoothly and provide continuous insight into the data that organizations collect.

DataOps is not a brand new concept. People like Andy Palmer have been writing about it for a little while now. But the term and the idea have yet to gain nearly as wide a following as DevOps. (There is not yet even a Wikipedia entry for DataOps—and you know an idea is still in its infancy when no one has taken the time to write about it on Wikipedia.)

Making DevOps Bigger

Meanwhile, from the DevOps perspective, the growth of interest in DataOps is significant because it exemplifies the broad applicability of DevOps principles. So far, the DevOps conversation has focused on the relatively narrow context of software development and delivery. But it can extend much further, too. DataOps is a start.

So, if you’re a data analyst, storage admin, data security professional or someone who works with data in any other capacity, it will be worth your while to borrow some ideas from your DevOps brethren. And if you work in software development, testing or delivery, it may be worth your time to educate your data friends on DevOps principles. It will make their workflows more efficient, while introducing DevOps to a wider audience.

— Chris Tozzi

October 13, 2016
Keep Applications Running by Testing Early, Continuously

Almost every product we buy or use today goes through some form of extensive testing before it’s released on the market; typically, these tests are designed to replicate the worst-case scenarios that a product may encounter under real-world conditions.

Automobiles, for example, go through extensive hot and cold weather testing in remote locations, and are driven over obstacle-laden tracks designed to push the limits of their durability. Even seemingly mundane objects such as children’s toys are exposed to abusive simulations to ensure that they don’t harbor any potentially hidden and harmful effects.

On the current landscape, applications are the face of your business, often serving as the battleground where consumer loyalty is won or lost. Given this reality, it seems crazy to think that any applications are released having only been exposed to a minimum of tests. Yet, in the name of getting to market quickly, that’s far too often the case.

As disciplines including agile and continuous delivery continue to increase the speed at which development teams can release software, it’s easy to put the crunch on testing in the rush to get an update released. But that’s a costly mistake in the long run, as research has shown that it is 50 percent less expensive to find an error in testing than to address the same error once it has reached production, and more than 90 percent cheaper when addressed in the development/coding phase.

Given the dramatic cost savings of addressing errors in development, clearly the goal of any organization focused on continuous delivery should be to shift testing left so a greater number of defects are found early in the development process. This is what we refer to as continuous testing, and it’s a huge part of the reason why I am so excited about CA’s acquisition of BlazeMeter.

Performance load testing should be a core element of any continuous testing strategy because it is a critical factor in determining system reliability. Similar to the worst-case scenario testing that consumer products undergo, performance testing can quickly uncover applications defects that might otherwise go unnoticed. After all, the manner in which a system operates with a few hundred concurrent users may be very different than how it runs with thousands of users.

BlazeMeter enables today’s development, operations and DevOps teams to conduct this critical performance testing earlier in the development process, saving countless hours and resources. The company is also competing—and winning—in a highly competitive marketplace where it has been pitted against much larger, more entrenched competitors.

Part of the reason BlazeMeter is winning is its focus on offering a SaaS-based solution that is highly cost-effective and easy to engage. Using this model, customers can try out the testing software with a few clicks, and then quickly move forward to broadly adopt the system. Another catalyst to its success: BlazeMeter was built using open source tools, such as Apache JMeter, used widely in the development community for performance and load testing. As a result, BlazeMeter can easily run and analyze JMeter and other open source-based load tests—such as Selenium, Gatling and Locust—within a commercial-grade performance testing system.

This combination of a SaaS delivery model and incorporation of open-source tools, augmenting strong performance testing functionality, make BlazeMeter very complementary to CA’s existing continuous delivery solutions, including its CA Service Virtualization, CA Test Data Manager, CA Agile Requirements Designer and CA Release Automation products.

At CA, we’re committed to providing the most comprehensive, integrated and open continuous delivery ecosystem, allowing our customers to release swiftly, test agilely and constantly increase reliably. The addition of BlazeMeter will further enable customers test continuously, thereby increasing agility and the overall quality of their software, to ensure that applications don’t break down on the side of the virtual road.

— Aruna Ravichandran

October 12, 2016
Last-Mile DevOps: How to Keep Employees Happy
Chances are that your company is embracing DevOps to make sure you can get fresh, new digital capabilities to your customers ASAP. That’s because in today’s market, you either have to be first—or quickly close any gaps between you and your more digitally innovative competitors.

But when it comes to getting new capabilities into the hands of your own employees, things probably move much slower. That’s because your internally facing apps have to clear a hurdle that your customer-facing apps don’t: administration of access privileges that often are poorly defined and inadequately automated.

That’s a problem. People can’t be productive if they don’t have access rights for the IT resources they need, when they need them. The growing Millennial workforce is going to be especially unhappy if IT is slow to meet their digital needs. And from a security perspective, slow administration of access privileges is also a problem—because your company must be able to automatically and immediately revoke employee access privileges the moment they’re fired or they quit.

This automated, accelerated management of internal users’ access rights is the missing “last mile” for DevOps. And it’s something you have to address if you’re going to fulfill the needs of the business with the same excellence as you fulfill the expectations of your customers.

What Makes the Last Mile So Tough?

If you bank with Chase or ride with Uber, your access to your personal data is gated by your personal login. But, as a customer, you essentially use the same app as everyone else.

Application privileges within your own company are entirely different for two reasons:
- Privileges for your internal workforce are much more complex than for customers. Salespeople have sales apps. Your finance department uses finance systems. Your service reps may be allowed to see RMA numbers, but not SSNs. So you must quickly give each person access to only the resources appropriate to their specific role and responsibilities—or risk consequences that include lost productivity, security breaches, compliance failures and excess software licensing costs.
- Management of internal privileges is an ongoing activity. Productivity, security and compliance demand that you provision each user account for each application with the right privileges at the right time. Privileges must be immediately and appropriately modified every time an employee is promoted or transferred. Privileges must be terminated immediately when someone leaves your company. Privileges may also have to be temporarily modified in real time due to session context—such as use of non-secure public WiFi or an access attempt from a questionable location or at a questionable time.
Simply put, for internally facing apps, getting code onto a production server isn’t enough. You also need to automate and accelerate management of the “last mile” between servers and employees.

What Are ‘Last-Mile’ DevOps Requirements?

DevOps toolchains automate and monitor the software life cycle from design and development through testing and deployment on a production server. What’s missing is automated provisioning and governance of the “last mile” between the server and the individual worker.

These tasks include:
- Capture of current user role/responsibility profiles from HR
- Provisioning of application-specific accounts with profile-appropriate privileges and controls
- Self-service inputs from authorized LOB managers
- Detection of session context (network connection, time of day, location, etc.)
- Real-time modification of privileges based on that session context
- Automated revocation of access privileges upon termination, transfer, etc.
- Employee self-service for permitted optional applications and services
- Monitoring and reporting on employee account activities and events
Your team probably performs many of these “last mile” tasks manually. Some may also be automated using homegrown scripts. Excessive dependency on scripts is a bad practice, though. Scripts usually are poorly understood by anyone but the original writer—which makes them difficult to maintain and update over time. They also don’t typically integrate well with DevOps, HR systems or other key pieces of the app delivery puzzle. This lack of integration slows your processes down and opens the door for human error.

Automation of last-mile DevOps makes much more sense. Automation speeds processes, reduces cost and optimizes accuracy. Integrated automation also gives you a dependable, centralized point-of-control for defining and editing policies—as well as for capturing the event logs necessary for compliance and security reporting. The right automation solution will also integrate with the rest of your operations environment (including directories, VDI, and mobile management tools) to ensure secure, reliable application access.

Why is ‘Last-Mile’ DevOps Important?

Most business leaders already understand why rapid rollout of customer-facing applications is so important. Unfortunately, many fail to recognize the importance of being just as fast and accurate when it comes to supporting their own workforce.

The truth, however, is that automation of last-mile DevOps benefits your business in several important ways:
- Improved employee productivity and engagement. Your workforce will be much more productive and more engaged when everyone has immediate access to the digital tools they need. That improved employee performance will benefit your customers as well.
- Higher IT efficiency. The sooner you automate the many everyday service provisioning tasks that your skilled IT staff now performs manually, the sooner they can to shift their precious time and energy from routine work to higher-value projects.
- Enhanced security and compliance. Well-defined access policies, diligent enforcement of those policies with rules-based automation and centralized logging of access provisioning activities all reduce your IT-related risks—as does immediate, automatic and complete revocation of all access privileges the moment any employee or contractor is terminated.
- Reduced “Shadow IT.” When IT is more responsive to people’s needs, they are far less inclined to turn to alternative digital resources that aren’t properly monitored, governed or secured.
- Greater business agility. M&A, reorgs and other organizational moves are chronically bottlenecked by manual execution of mass changes to the workforce’s digital access privileges. Rules-based automation of last-mile DevOps eliminates this agility-killing process friction.
The bottom line: To achieve true digital agility, your company must automate the “last-mile” tasks that give your people access to the IT resources they need—when they need them.

About the Author / Stacy Leidwinger

Stacy is the VP of Products at RES where she is responsible for defining overall product direction, roadmap and positioning, to drive product excellence, company growth and customer success in the areas of end user computing and security. Her background is in both product marketing and product management helping to positioning B2B software companies for growth and market leadership. Prior to RES, Stacy led the product management team at Directworks, a cloud-based sourcing and supplier management solution. Before Directworks, she managed the roadmap, product positioning, and go-to-market strategy for Vivisimo, an enterprise search solution, which was acquired by IBM. While at IBM, Stacy was responsible for the integration of Vivisimo’s product line into IBM’s big data portfolio. Connect with her on LinkedIn / Twitter.
October 12, 2016
3 AWS Design Patterns to Maximize DevOps Value
Many business leaders are planning to make DevOps the cornerstone of their IT transformation strategy. But, as surprising as it might sound, skepticism abounds regarding how major vendors address the DevOps transformation challenges—they confuse DevOps with continuous delivery (CD) infrastructure.

“We wanted DevOps and we got after a nine-month-long implementation a continuous delivery platform which speeds up IT operations without significant business value. How differently can you help?” the senior business executive of a major financial institution in New York sarcastically asked me during a conversation three months ago.

The business executive is right: DevOps isn’t a technology as I’ve been implementing it, it’s primarily an accelerated application delivery approach implemented in the form of a technology-enabled application delivery operational model. Adam Jacob, CTO of Chef, substantiates that fact in “The Secret of DevOps: It’s Always Been About People, not Technology,” when he says, “DevOps is about bringing together all the people you need to build and run your business effectively, and empowering them to move as quickly as possible towards their goals.”

Agile Admin’s Ernest Mueller in, “DevOps: It’s not Chef and Puppet,” confirms Adam’s point: “Chef and Puppet are individual tools that you can use to implement specific parts of an overall DevOps strategy if you want to use them—but that’s it. They are fine tools, but do not solve DevOps for you.”

How can we implement DevOps in line with business leader expectations? Three Amazon Web Services (AWS) Design Patterns I developed can help to get the best of DevOps on AWS cloud: Software Organization Factory, Digital Organization Factory and CD Infrastructure Factory. This article discusses the Software Organization Factory.

The Foundation of DevOps Value: Consequences to IT Service Delivery

Before delving into these AWS design patterns, a quick reminder of what DevOps is, its value propositions and, more importantly, what changes are needed in how IT services are delivered.

The Ignored DevOps Business Logic We All Must Consider

The combined effect of cloud adoption and the rising digital economy is changing competitive environments; it forces business leaders to focus on innovation and market responsiveness as the competitive differentiators.

The fact of the matter is, by facilitating access to technology, cloud accelerates entrance of several thousands of tech startups that take advantage of the recent technology innovations to substitute traditional products and services into digital. This creates a context where new entrants increasingly compete with established brands, forcing business leaders to seek value paradigms other than IT efficiency.

The business executive argues, “In these new markets, our concern is to increase customer value by delivering the right services to the right segments at the right moment. You guys need to change the IT paradigm; IT alone does not create that kind of value.”

Then, what should be changed in today’s IT approach?

The Two Dimensions of Modern IT: The Operational Model and the Continuous Delivery Infrastructure

The new IT paradigm advocated in my recent book, “Rethink Your IT with DevOps: The Complete Guide to Aligning Your IT to DevOps,” is the idea that business value results from two dimensions: organizational agility and technology efficiency. In other words, it defines modern IT as a two-dimension asset including the operational model and the continuous delivery infrastructure.

The timely delivery of innovation transcends IT issues; it not only cuts across your sales, marketing, post sales, application development and IT operations, but also demands concrete answers as to how to accelerate business prioritization, decision-making and problem solving. The operational model is where business and IT people, processes, practices and tools are combined to create agile and cross-functional environments. The following exhibit shows a typical DevOps operational model:

Typical DevOps Operational Model

Organizational flexibility for the sake of flexibility doesn’t make sense unless technology is leveraged to speed processes. This is where CD infrastructures come into play; throughout the delivery process, they build on IDEs to accelerate coding and testing, on versioning tools to convert software version into releases, on continuous integration (CI) tools to build releases and on delivery pipelines to ensure continuous delivery.

So, what is DevOps?

DevOps is a Technology-Enabled Application Delivery Model

DevOps is a combination of value, principles, processes and practices shared not only by developers and IT operations but also by the business. The goal is to help the organization deliver the right service to the right market segments at the right moment.

DevOps from the Business Perspective

As I’ve been implementing it, it’s a cross-functional application delivery model involving the business and IT and enabled by continuous delivery infrastructures.

By enabling and automating agile practices, the continuous delivery infrastructure makes the operational model agile and provides the business with the flexibility and velocity needed to meet competitive challenges.

Design Patterns as DevOps Implementation Engineering Framework

As suggested by the business executive, today’s DevOps implementations struggle to deliver the promised business benefits. The reason is, the operational model dimension is ignored in favor of tools and infrastructure.

Another reason is, DevOps is young and is still at the early stage of the technology maturity model; the expertise and engineering methodologies to implement it as what it is—a technology-enabled application delivery model—are lacking. That’s where DevOps transformation design patterns help.

What are DevOps Transformation Design Patterns?

In this article, the term DevOps transformation design patterns refers to general reusable architectures addressing specific DevOps strategy. They’re not necessarily implementable solutions, their primary goal is twofold:
- Offer a neutral language for designing and implementing technology-enabled operational models
- Offer an engineering approach that reduces design and implementation duration and effort
They’re formalized architecture design and implementation best practices for DevOps and platform-as-a-service (PaaS) services.

Design Pattern as DevOps Implementation Engineering Methodology

To meet its goals—technology-enabled application delivery model—the design pattern is structured around four items including purpose, principles, general solution and implementation techniques.

Purpose: Clarifies the purpose of the design pattern along with the DevOps strategy to address.

Principles: Are best practices formulated as rules and beliefs supposed to guarantee expected DevOps strategy benefits? They’re the determinants of the solutions to implement the DevOps strategy.

General solution: Are blueprints resulting from the application of principles? They summarize the functional and technical architecture of the DevOps platform to implement.

Implementation techniques: What are recommended technical approaches, solutions and tools to implement the general solutions?

Why AWS? Why would it be the catalyst for DevOps value?

AWS-ome Design Patterns That Will Change DevOps Implementation

AWS offers such a rich, varied and easy-to-implement services portfolio that it would be unfortunate not to take advantage of it to modernize IT. The rationale underpinning the value businesses can derive from their DevOps transformation experience with AWS is summarized in the following figure:

Rationale of the DevOps Design Pattern

It’s the belief that:
- Certain principles determine the AWS services needed to deliver the application delivery model (ADM) architecture that guarantees value.
- The implementation of the ADM using these AWS services results in AWS-based DevOps platforms that tangibly deliver expected benefits.
The Four DevOps Principles that Yield AWS Value

Let’s explore the principles I’ve been using to make CIOs happy with their AWS cloud:
1. Think holistic, not only IT: Reminds that transformation isn’t only about IT but the entire organization’s value stream from marketing and sales to development and IT operations.
2. Think cross-functional, not only IT: Reminds that the bottom line is to set up a cross-functional application development environments to accelerate business prioritization, problem-solving and decision-making, and meet time-to-value objectives. They’ll be the core value propositions of the DevOps platform.
3. Make it agile, flexible, and speedy: Reminds that agility, flexibility and speed are the catalysts for competitiveness and business value. They’ll be part of the DevOps platform.
4. Think PaaS: Reminds that AWS provides varied services for implementing state-of-the-art CD infrastructure.
Let’s illustrate three AWSome design patterns that’ll change DevOps experience with AWS!

Implement a Startup Mindset with the Software Organization Factory

The purpose is to implement DevOps strategies focused on time-to-market and time-to-value. It’s adapted for tech startups.

To implement the startup mindset, the DevOps four principles for AWS are implemented as follows:
- Think holistic and cross-functional, not only IT: Relevant business and IT resources are put together in a single and dedicated service development team supported by appropriate Scrum and XP agile practices.
- Make it agile, flexible and speedy: PaaS services building on agile practices and AWS infrastructure-as-code are provided to make application delivery processes agile, flexible and speedy.
- Think PaaS: AWS infrastructure as code and DevOps tools are combined to implement a CD infrastructure in the form of a PaaS platform.
The DevOps platform resulting from the principles application is illustrated below:

Software Organization Factory

The “Startup Mindset” platform is structured around three components including the cloud-enabled operational model, PaaS and the CD infrastructure.

The operational model builds on a three-stage application delivery life cycle:
- Plan & measure: It mobilizes business users, development, QA and operations staff on business prioritization issues using agile practices such as Scrum product backlog planning or XP’s user stories.
- Develop & Test: It mobilizes business users, development, QA and operations staff across the development life cycle using agile techniques such as Scrum iterations, XP’s test-driven development (TDD) and behavior-driven development (BDD).
- Release & Deploy: It leverages continuous integration practices to build and test releases prior to deploying to production.
- Monitor & Improve: It’s outsourced to keep the service development team on its core business: developing software.
The CD infrastructure combines the followings services:
- AWS CodePipeline and CodeDeploy to set up the delivery pipeline.
- AWS infrastructure as code including CloudFormation, OpsWorks and Elastic Beanstalk to generate the CD infrastructure.
Summing It Up

The DevOps business benefits are real, yet, it’s young and is still at the early stage of the technology maturity model. The expertise and engineering methodologies needed to implement it as what it is—a technology-enabled application delivery environment—are lacking.

DevOps design patterns such as the software organization factory fill the gaps of today’s transformation practices:
- They provide the architect team and the executive team a neutral language to discuss the business, technological and technical challenges and solutions.
- By pointing out the agile practices to leverage, they simplify and accelerate the design and deployment of the operational model.
- By pointing out the AWS services and features to leverage they facilitate the design and implementation of the CD infrastructure.
The DevOps implementation process described in this article is fully documented in my recent book, “Reinventing Your IT with DevOps: The Complete Guide to Aligning Your IT to DevOps.”

In my next article I’ll tackle the Digital Organization and the CD infrastructure design patterns.

— Philippe Abdoulaye
October 11, 2016
Taming 2 Cloud App Performance Enemies

Whenever you hear the words “the network’s slow today,” or, even worse, “the network’s down,” you know somebody miscalculated. It may have been the person who decided to buy the wrong hardware, or maybe the one who signed up the wrong telecom provider.

Often, that slowdown or outage was the result of somebody underestimating server demand or overestimating the amount of redundancy built into the network setup. It’s always tricky finding the right level of redundancy that will keep users from waiting for their data without overspending on cloud capacity.

A common mistake IT managers make when switching from in-house infrastructure to cloud infrastructure is failing to take advantage of the flexible, affordable, redundant capacity offered by Amazon Web Services, Microsoft Azure and other cloud providers. That’s the conclusion of Yan Cui in a April 20, 2015, post on his “The Burning Monk” blog.

Cui points out that latency is inevitable because things go wrong—and usually, those things are beyond your control. That’s why you have to design your applications with latency in mind. Too often developers work inside a bubble, where all hardware and network parameters are geared to the tasks at hand. In the real world, hardware, networks and software break. If your app isn’t designed to accommodate such failures, you’re leaving your users in the lurch.

Get Real: Inject Latency in Your Test Environment

To model app performance in real-world settings, it isn’t enough to test servers and databases under anticipated loads. You have to take the extra step of mimicking the glitches that are as inevitable as they are unpredictable. Cui proposes injecting random latency delays on every request. He even provides a simple PostSharp attribute that automates the process.

Cui applies the concept of error-planning even further by introducing errors in the mechanism used to throttle requests to prevent bad guys from spamming their servers using such tools as Charles and Fiddler, or any of the spammers’ own bots. By making the errors visible in the dev environment, designers can anticipate them and engineer ways to handle the throttling errors “gracefully.” Once again, a PostSharp attribute is applied to randomly inject throttling errors; Cui states that the same approach can be used to plan for and respond automatically to session expiration, state out-of-sync, and other service-specific errors.

These and other error-detection and -correction methods fall under the umbrella of Design for Failure, a principle championed by Simon Wardley as a key characteristic of next-generation tech companies.

Simon Wardley’s Design for Failure contrasts the development approaches of traditional shops and those he identifies as “next generation.” Source: The Burning Monk

Cui explains how modeling latency and other errors within the development process has been applied by Netflix’s use of Chaos Monkey and Chaos Gorilla, as well as the mechanism Uber devised to allow its client applications to fail over seamlessly in response to a data-center outage.

Learn How to Combat Latency from the experts: Gamers

Nowhere does server performance matter more than in the world of online games, where one-microsecond hiccup can spell the difference between winner and loser, champion and chump. In an April 17 article on Venture Beat, Cedexis’s Pete Masden explains that a 500-millisecond network delay makes an online gamer twice as likely to walk away, while a 2-second delay in load time leads to abandonment rates as high as 87 percent.

Addressing latency begins by measuring it, according to Masden. That’s why we added native monitoring to Morpheus when we built the cloud management platform. Being able to see the status of all your organization’s apps and business services at a glance isn’t just a nice convenience—it’s a competitive advantage. To be able to glance the status of all your organization’s apps and business services, group databases, app servers, messaging queues and web servers by system dependency and impact to view an overall status as well as each app’s current state is crucial to knowing what’s happening in your organization.

One approach to cloud-server latency is to create separate instance, which is common for failover but less so for addressing regional network demand. Rather than the traditional active-passive model, however, Masden recommends an active-active approach when implementing multiple redundant instances to ensure all servers are up to date and optimized. Atop the multiple instances runs the global traffic analyzer to ensure no single instance becomes overly congested.

Is ‘Zero-Latency Computing’ Even Possible? Why not?

If you think network latency is a problem now, just wait until such technologies as 5G, the internet of things (IoT), virtual reality (VR) and robotics go mainstream. Equipment and bandwidth upgrades, and more sophisticated software-defined networking won’t be sufficient to address tomorrow’s application-performance needs. That’s the conclusion of Nitin Serro in a Sept. 29 post on the Channel Partners blog. Serro identifies three technologies as key to meeting future performance requirements: network functions virtualization infrastructures (NFVi), fog computing and zero-latency computing.

The applications made possible by 5G and related technologies come close to eliminating latency by shifting more intelligence directly to the network, not merely by providing faster speeds. Source: GSMA Intelligence, via The Unwired People

While NFVi and fog computing focus primarily on the network and data layers (compute, storage and network infrastructure), zero-latency computing targets the application layer, where information has to be exchanged in real time between diverse components, most of which link directly to users. According to Serro, nothing short of an entire re-invention of the network infrastructure—from backbone to edge—will prevent today’s bottlenecks from becoming tomorrow’s blockages.

Move the Network Intelligence Closer to the Data

The network-capacity challenge we now face is unprecedented, according to Silicon Republic’s John Kennedy, who writes in an Oct. 3 post that even the much-touted 5G network will come out of the gate hobbled by the need to accommodate its many predecessors. Rather than the “step change” in network speed that most analysts expect, 5G will deliver a tremendous boost to network intelligence. This may be the technology’s greatest asset: a smarter network means the data doesn’t have as far to travel.

From an application-design perspective, latency can be traced to three sources: the need to link to legacy infrastructure, the need to link to third parties via APIs and the innate unpredictability of the internet itself. Marqeta’s Dave Matter examines these situations from a payment-processing perspective in a Sept. 13 post on App Developer Magazine.

As with the network infrastructure itself, the solution to application latency is to move more of the intelligence into the app itself and then rely on open APIs to link data sources in real time in an environment that’s closer to users. Once again, the data and associated analytics tools have less distance to travel, and much less latency to deal with. Ultimately, the solution to latency—in hardware and in software—will be fewer, shorter trips.

— Brian Wheeler

October 10, 2016
Creating a Continuous Integration Delivery Pipeline
This article will provide an example delivery pipeline used through continuous integration, as well as the DevOps tools involved in the automation of building, testing and deploying code through your software development life cycle (SDLC).

Background

These days, it’s almost impossible to go anywhere without hearing about DevOps. In short, DevOps is the effort to improve communication and synergies between development organizations and operations organizations—hence the term, “DevOps.” The main focus is to improve the efficiency, quality and speed to market within the software development world.

Today, you also may hear and see a lot about continuous integration and continuous delivery/deployment. There are differences between the two for sure, but for simplicity’s sake, this blog focuses on breaking down the different stages of the process. This way you can get the basics and hit the ground running with a delivery pipeline in your organization. The delivery pipeline can be broken down into a few major buckets of work, or stages, as mentioned below.

In my opinion—and, again, trying to keep things simple for now—the stages can be broken down as follows:
1. Source Code Control (Management)
2. Build Automation
3. Unit Test Automation (could also include Integration Testing here as well)
4. Deployment Automation
5. Monitoring – not included in this discussion, and can be added at any time
I have outlined the progression of these stages in Figure 1 below. Let’s review each of the stages in a little more detail.

Figure 1 – Continuous Integration Delivery Pipeline Sample

Source Code Control (Management)

Background

Source code management, or source code control, certainly is not a new topic. This has been around for decades and has evolved over time. In a nutshell, an organization stores its code in a source code control system or repository so it can be tracked, maintained, versioned and audited. Developers should not store the code on their laptops or virtual machines and trust that will suffice for managing the code.

Possible Tools
1. Git is probably the most widely used SCM system out there. It is an open-source system.
2. Subversion (SVN) has been around for quite some time. It is also an open-source system and is heavily used in many organizations, but there has been more of a push toward Git.
Git and Subversion comparison can be found here.

Build Automation

Background

Once a source code management system is in place and actively being used by a development team, the team will need to be able to compile and build their code. This is probably the first step in the whole chain of continuous integration events—it’s what gets the ball rolling. The code needs to build cleanly before an organization can even think about deploying out to its environments for testing and production.

Possible Tools
1. Gradle is an open-source build automation system used by top companies including Netflix, Google and LinkedIn.
2. Maven is another open-source build automation system.
Gradle and Maven comparison can be found here and here.

Unit Test Automation

Background

Developers unit test their code to ensure the functionality they are building works as expected. In an ideal world, the development team should be saving these unit tests so they can be reused and put into a regression test bed.

Possible Tools

There are multiple tools out there for helping developers unit test their code. Many of these tools are open-source and can be used freely.
1. JUnit is an open-source unit test framework pretty widely used.
2. CA DevTest allows for the automation of unit testing, as well as a few other bells and whistles, such as service virtualization.
Deployment Automation

Background

For the last stage in the process, delivery teams need to deploy their code/applications out to various test environments and, of course, production. To reduce errors and overhead in the deployment process, while increasing speed to market, this step can be automated through a variety of tools and methods.

Possible Tools
1. IBM Urbancode uDeploy allows users to model a process and orchestrate their deployment. This process then can be repeated across all an organization’s environments, and tweaked for each environment as needed.
2. Ansible is an open-source IT automation tool. It can be used for everything from configuration management to product installation to application deployments.This tool is rapidly gaining acceptance and momentum in the DevOps community.
Conclusion

This was simply a quick overview for companies to get started down the path of continuous integration and the DevOps world. Figure 2 is an example of what the whole flow looks like from committing the code to repo to deploying the code to an environment, to help put things into perspective. It’s easy to see how the tools interact with each other on the journey to production.

Figure 2 – Continuous Integration Process Flow

About the Author / Seth Gagnon

Seth Gagnon is a Middleware / Infrastructure / DevOps architect with more than 12 years’ experience in the field. Please visit sethgagnon.com for additional related articles. Connect with him on LinkedIn and Twitter.
October 6, 2016
Get to Know the New DevOps Stack

Deploying software has always been manual and labor-intensive. That’s fading into the past as continuous innovation has become a competitive differentiator for companies of all stages and sizes across every industry.

DevOps has become a hot investment market in recent years. The mega-rounds we’ve been seeing show the massive demand for tools that enable optimal runtime. Moreover, IT leaders are ready to spend to promote the DevOps culture.

Companies increasingly are turning to DevOps processes and tools to automate the development life cycle and position themselves to adapt and scale nimbly. But for some companies, the idea of completely overhauling their IT operations processes can seem daunting—they don’t know where to begin. The thing is, adopting DevOps is actually quite simple.

Examining the Stack

Developers should bake in automation and agile development from the beginning. The good news, though, is that a defined set of tools to automate each step of the deployment process has emerged. Here’s a breakdown of the new DevOps stack, layer by layer:

Source Code Repository: Let’s start from the bottom of the stack—from the moment you write the first line of code. Before the open-source movement took off and the cloud enabled easy sharing, developers had to work much more slowly to ensure that the necessary improvements were inserted in the right version of a product. Companies such as GitHub, Atlassian and GitLab provide source-code repositories that facilitate collaboration. Now, engineers can work on the same projects at the same time from halfway around the world without worrying about duplicating efforts.

Continuous Integration: Newer tools such as CircleCI and TravisCI, as well as older tools such as those offered by Jenkins, automate testing and integration and provide repeatability in the deployment process. Using these tools, developers are able to test their code for failures and bugs as they write it so the code can be fixed before users ever experience the bugs. CI tools give developers something they desperately need to succeed in today’s competitive marketplace: timely feedback. By spending less time waiting on feedback for new code, engineers can resolve software bugs before they grow into full-scale crises.

Binary Repository: Jfrog and Sonatype provide an end-to-end solution for storing and managing binary artifacts. The binary repository is the system of record closest to the production runtime environment. When something goes wrong, a binary repository such as Artifactory is the first port of call for operations teams. In addition, these tools scan for security vulnerabilities and make it easy to seamlessly distribute software to every corner of the globe.

Continuous Development: Companies including Chef, Puppet and Ansible automate the next phase of taking data into production. The holy grail for software developers is zero downtime; continuous development tools allow developers to update software while everything remains up and running. These tools also streamline the delivery process by automatically configuring servers and ensuring repeatability of the deployment process.

Production Environment: Google Cloud, Amazon Web Services and Microsoft Azure are in a war over runtime market share in the public cloud. Behind the firewall, Mesosphere, Kubernetes and Docker are trying to dominate the orchestration layers of enterprise private clouds. Customers want the agility and automation that comes from a cohesive DevOps stack but are refusing to be locked into a single vendor at any level. Whichever stack emerges as the default DevOps stack will have to ensure compatibility across public and private clouds.

About the Author / Andy Vitus

Andy Vitus is a Partner at Scale Venture Partners. He has been investing with Scale for over 12 years and focuses on next-generation enterprise software and new data center technologies, including virtualization and cloud computing. Andy sits on the boards of Arena, Crittercism, DataStax, JFrog, PubNub, Realm Stormpath and Treasure Data. Connect with him on LinkedIn and Twitter.

October 6, 2016
DevOps: Using Games to Make it Practical

This blog stems from my experience of being one of the earliest DevOps Foundation trainers of DOI and successfully completing 19 batches of DOI Foundation course in the last year.

In retrospect of the year starting when TaUB Solutions signed up as a registered education partner (REP) of DOI, my opinion is this has been the best service portfolio offering for our customers and partners.

There are few things that appeal best when it comes to DOI Foundation course and I can summarize them with the collective feedback I’ve received so far:

“Challenges the preconceived myths and practices around DevOps with practitioner stories.”

“Gives a holistic overview of philosophy behind DevOps. Philosophy should precede science and science should precede engineering.”

“This course maintains the discipline to be truly advisory in nature by illustrating tool chain without recommending vendor-specific tools.”

“The group exercises during the class and the facilitator practical insights helped us to put the aspects in to our organizational context of delivering products and services.”

“We have never seen a course such beautifully designed that could be the first basic building block to know ‘Do’s’ and ‘Don’t’s’ of DevOps across application developers, infrastructure operations, project managers, infosec professionals and business leaders.”

To enhance the overall learning curve of the audience, we put them in to the third day of experiential learning using the Phoenix Project Business simulation. The simulation was divided into four rounds and played with maximum of 12 people per batch. The Team was entrusted to achieve a target of $300,000 within four rounds and take the share value from $21 to $45.

While the target milestones were clearly laid down at the beginning of game it was difficult for the teams to get hold of the situation due to various unknown parameters. It took them quite sometime to understand the different moving parts of flow, dependencies, business impact of projects, issues and features that came up in every round and make appropriate choices and decisions.

The teams experienced significant learning, sharing and collaboration over the four rounds and had loads of fun. One common feedback from the teams was for the game to be mandatory after every two-day DevOps Foundation course.

The consolidated feedback after playing the DevOps business simulation after the two-day course:

“It demonstrated that it is not easy to build collaboration, communication and integration. It takes time and there is a lot of patience and team work needed to make this a reality. The DevOps culture had to be nurtured through self-organizing teams with mutual respect, sense of pride and collective ownership to work toward a common goal.”

“It gave a working knowledge on how ITSM and DevOps are complementing each other [Ex. Change Management and Improved Flow].”

“The Principles of DevOps, namely the First Way (Improve Flow from left to Right), Second Way (Shorten Feedback Loops) and Third Way (Repetition through Mastery) was visibly evident over the course of four rounds.”

“The speed of execution improved over the rounds using short feedback loops, continual improvement and applying lessons learned from previous rounds.”

“It gave a good understanding of how different roles and responsibilities in the organization contribute to the overall success of the project.”

Finally, the teams made over and above the required target of revenue and stock price. The winning moment was enhanced by the significant learning opportunity and ability to bond with diversified cross functional teams.

The experience of playing the business simulation reinforced practical understanding of DevOps and also transferred skills that they could implement immediately at their workplace.

About the Author / Suresh GP

Suresh GP is the Managing Director of TaUB solutions and Regional leader of BRMI (APAC). He has more than 15 years of experience in IT Service Management, IT Governance, Program Management and Organizational Change Management. He is regular blogger and International speaker at itSMF UK, itSMF Australia, itSMF USA, itSMF Finland and itSMF Norway. He is a Certified DevOps, Agile Service Manager, Business Relationship Management Professional, PMP, CGEIT, ITIL V2 Service Manager, ITIL V3 Expert, ISO 20000 practitioner. He was awarded the ITSM contributor of the year by itSMF Singapore in 2013.

October 5, 2016
Alerts Keep DevOps Teams Responsive, in Sync
Continuing our five-part series on “Continuous Monitoring: The Role of DevOps and APM,” this blog post will talk about how alert notification can help DevOps teams be more productive and agile.

Amid the constant, rapid change and fluidity typical in DevOps organizations, there are some undeniable absolutes. These absolutes, present at each stage of the DevOps life cycle, demand your teams’ attention: A build or test succeeds or it fails; an outage of an app in production is restored to service or it lingers unavailable; users applaud or they blast out complaints. And with each of these states throughout the DevOps life cycle there are absolutes common at every step: Your team is either communicating or they are isolated, and, subsequently, either in sync or operating in confusion and chaos.

This is still common, but avoidable. The means of communication are more abundant than ever. We can text, email, use collaboration apps or even the obscure method of speaking into a telephone to another human in real time. Yet, despite all these methods, DevOps teams still find themselves taking too long to become aware of issues that need immediate attention or action. Or, we realize too late that multiple people are responding to or chasing down the same issue. Ironically, the easier it is to communicate and even automate communication across all of the different methods, the more likely we get inundated and saturated by what we really need to be paying attention to.

What’s the best way to cut through all the noise? DevOps teams can:
1. Filter the junk and cut down on the noise to begin with—without missing something important.
2. Direct the relevant info only to those people that need to take action, and only when it’s the appropriate time.
3. Require an acknowledgment that the recipient is taking ownership of the issue.
4. Or, of course, all of the above.
There have been tools available over the years to tackle these noise-slaying objectives. Some do a great job getting info to our team’s pertinent DevOps information, but with no way to filter out the irrelevant or redundant stuff. And others can do some of everything, but are complex to set up and maintain and expensive to use.

DevOps teams I’ve talked to want to be able to:
- Immediately and automatically send critical, actionable alerts.
- Route alerts to the right people immediately, but only when it is the appropriate time to do so (don’t wake up the wrong teammate!).
- Speed alert response with automated acknowledgment and escalation.
- Automatically communicate through text, email, voice mail and mobile app, all custom-designed for DevOps use cases.
The prevalent expectation goes beyond easy-to-use, simple to start and maintain solutions. Effective tools also must meet the increasing demand for agile and efficient collaboration among DevOps team members who often use multiple communication tools.
- Filter out the noise, but don’t miss the important stuff:
  - Filter alerts, (e.g. by problem severity), so you can focus on real problems and disregard IT operations noise. Create custom groups of contacts to make sure the right notifications reach the right team member, and streamline the process of determining who to contact when specific problems occur and how to contact them.
- Notification channels:
  - Define experts who can respond to problems and store their contact details so they can be notified automatically of problems in their area of responsibility. Users should be organized into groups and so you can send notifications to several users at once. Notifications should able to be sent by email, SMS, mobile app, voice message and chat apps.
- Alert management and notifications:
  - Tools with policy-based notifications can let you define which type of subject matter you want each person or group to be notified about. You should be able to create filters based on the alerts that occur, customize the filters and assign users and groups who are notified when matching problems occur. Unacknowledged alerts should be escalated automatically after a set time period to the appropriate contact. Filters such as the severity and status of alerts can be created for your IT monitoring requirements.
- Scheduling:
  - You’ll want to be able to easily set up on-duty and on-call shifts. The process of scheduling is considered to be one the most time-consuming tasks that prevent users from utilizing a notification tool. A good scheduling capability should be intuitive and require minimal steps to use. Users should have the ability to customize or use out-of-the-box templates. Users also should be able to manually create shifts or build in shift patterns, such as follow the sun, to get their scheduling done faster. Scheduling capabilities also should be smart enough to schedule users or groups for weeks in advance.
- Alert viewer:
  - You’ll also need to be able to monitor alert and notification status in management views, perform actions on alerts, and track them in real time. Seeing key alert information such as alert severity can help you enable to easily prioritize your to-do list. You should be able to track alerts from their receipt by the system through acknowledgment to resolution and changes in an alert history, and use predefined and real-time filters to designate alerts you want to see.
Utilizing the capabilities such as these can empower you to improve responsiveness, save resolution time and focus on actionable notifications requiring immediate attention.

About the Author / James Moore

James Moore is responsible for offering management and strategy for IBM IT Service Management hybrid cloud-based solutions including Runbook Automation and Alert Notification. James joined IBM from the Candle acquisition in 2004, where he was product manager for Candle’s Application Response Time product lines. James has more than 15 years’ experience in business service management, application performance management and event management. Connect with James on LinkedIn and Twitter.
October 5, 2016