devopsy.kinsta.cloud

Category: DevOps Toolbox

Raising the Bar on DevOps for Enterprise Systems
What do you do when you are a leader in DevOps solutions for Enterprise Systems and you practice what you preach? You raise the bar to continually improve your offerings and share thought leadership about where the future lies for clients as they navigate the world of continuous delivery in a climate of digital disruption.

The primary reason why most companies adopt DevOps is to reduce cycle times and to improve responsiveness to the market. This is accomplished by breaking down organizational and role-based silos and by allowing people across the end-to-end software lifecycle to work more closely together. While culture is the most tricky part of a DevOps transformation, tools play a major role in enabling information to rapidly flow across people and lifecycle phases, reducing manual and error prone steps, and alerting people of issues as early as possible so they can be addressed. A key feedback loop comes from development in small batches, where frequent compile, build, deploy, and test cycles, allow you to discover issues within hours of the code having been written.

Over the last month, IBM has made major announcement improving our DevOps for Enterprise Systems solution to help our customers to more easily realize the value of DevOps. Here is a summary of the many announcements we have made.
- Integrated Suite: We announced the new Enterprise COBOL Suite, which provides one integrated suite of five tools targeting developers and systems programmers. The suite of tools allow you to do performance analysis, analyze abends, code and do unit testing, debug problems and manage complex files and data sets. Click here to see for the next level of details.
- Frequent build and release: Many customers have concerns that a transformation to DevOps may drive up their MIPS cost with frequent compile, build, deploy, and test cycles. To mitigate this concern, we announced the Enterprise COBOL VU Edition consisting of Enterprise COBOL for z/OS V5.2. This edition allows you to increase your compiles up to a factor of 10x without an increase in your MIPS cost.
- Integration Platform: In the blog All aboard the z/OS release train – Aqua is coming, my colleagues Kenichi Yoshimura (@kyosh1107) and Joe Winchester (@JoeWinchester) discussed how Explorer for z/OS Aqua has been expanded into an integration platform across the DevOps lifecycle, with initial capabilities for Development (RDz and PD Tools), Operations (CICS Tools), and Runtime (CICS Explorer). The Aqua release improves the user experience for application developer and system programmers, makes installation easier by allowing all of the above rich client tools to be installed using one installer, and makes deployment easier through push-to-client technology.
- Drinking our own Champagne: We have also built a brand new continuous build, deploy and test infrastructure that is shared across our tools running on our integration platform, Aqua. This allows us to build, deploy and test plug-ins across our integration platform to ensure that they are compatible before we make them available to you. This means higher productivity for our development teams and better quality for our customers.
The whole intent behind offering a suite of products with continuously improved end-to-end integration is to enable teams to realize the value of their DevOps investments more quickly. While we will continue to bring our “A” game to the Agile software delivery court, I am interested in what innovations you see coming that would increase IT’s value to the business.

About The Author

Per Kroll is Director of DevOps for Enterprise solution in IBM zSystems Software unit, where he oversees offerings management, development and support. Per also co-leads a DevOps transformation of 2,000 developers within IBM zSystems Software unit. Per has focused on helping organizations improve how they develop software throughout his career. In past positions, Per drove development of the world’s most broadly adopted commercial process library (Rational Unified Process), development of a measurement framework, and lead an open source project centered on agile best practices. Per has also managed development organizations spanning a dozen countries, support, product marketing and product management organizations. Per has authored more than 30 articles and 2 books, sold in more than 30,000 copies and translated to 6 languages.

Follow Per Kroll on Twitter: @perkroll and LinkedIn: https://www.linkedin.com/in/perkroll
November 24, 2015
Continuous Operations: Implications on IT automation

With the increased adoption of cloud-based services, users are now accessing their applications through multiple channels and device ‘endpoints’. User experience expectations, which are constantly rising, now have to be met across multiple channels to avoid customers dropping of your website or app and never returning again. Minutes of service downtime or response slowdown may result in thousands of prospects and millions of revenue lost. This imposes enormous challenges on the operations of the applications and services, which have to ensure the permanent availability of applications and services.

A continuous truth

This means that operations of applications and data services need to be continuous without interruption. Availability and Performance cannot suffer from ongoing releases, updates and patches – downtime is a luxury of past times. Continuous monitoring of infrastructure, applications and services has to be tied to automated remediation. Events raised from monitoring trigger automated processes to add server nodes, storage or network capacity in a “hot” mode without service interruption or to re-distribute load to different locations and data centers to fix performance issues.

All of this is impossible without a solid automation architecture. Orchestration of automation is key.

Orchestration of automation has to ensure that different tools and systems in the operations management chain are properly connected and hand-off points are automated to achieve end-to-end automation across silos.

The operations management tool chain includes monitoring tools for the different layers as well as network and storage management, server virtualization, database management, application server management and IT service management.

With the right automation platform in place you will be able to connect these tools into fully automated end-to-end processes and at the same time ensure that these processes can be monitored and controlled in a reliable manner.

In addition, pay specific attention to automation of release and deployment.

It is hard to escape the increasing demand for faster releases to constantly introduce new features, improve usability, fix defects and security loopholes. At the same time, service interruption is not an option.

Only with the right deployment architecture and tools in place you will able to handle this challenge.

Continuous operations means users never even know upgrades have happened — until that is they start to enjoy the additional functionality experience that comes from the upgrade itself.

The end-to-end challenge

The challenge today is an end-to-end one. As Gartner research director Robert Naegle has said, “Gartner research shows that it is still more common to see automation technologies popping up in functional islands, with I&O management later attempting to aggregate and orchestrate disparate technologies, scripts and workflows.”[1]

The imperative now is one that centers on bringing continuous automation technologies to bear an end-to-end basis. In this way they can facilitate the seamless integration from the business processes through the IT services supporting those processes and the delivery of applications to differentiate the business.

[1] Gartner, ‘Hype Cycle for I&O Automation, 2015’, Robert Naegle, Gartner, 7th July 2015

November 19, 2015
Automic amps up DevOps with continuous everything

DevOps is all about automation and continuity. I’ve written in the past about continuous as a DevOps buzzword, and the continuous continuousness of DevOps because it seems like everything is continuous. There’s continuous delivery, continuous integration, continuous testing, continuous deployment, etc. Perhaps the executives at AUTOMIC read my work and it inspired them to skip straight to Continuous Everything.

DevOps is fundamentally about culture more than tools, but once the culture is in place the tools make all the difference and many of the tools revolve around automation. Every task that is routine and repeatable should be automated so that actual human beings can devote their time to more complex or important tasks. The goal of DevOps, ultimately, is to enable developers, IT operations, and other teams to work more effectively and efficiently.

AUTOMIC—a play on words that has “auto” as its root, but is pronounced like “atomic”—is focused on driving DevOps automation. The AUTOMIC Continuous Everything business automation platform is designed to help businesses by combining continuous delivery, continuous operations, and continuous services into a single, unified platform.

“Never has there been so much pressure on businesses to increase their speed of execution”, said Todd DeLaughter, CEO of AUTOMIC in a press release statement. “We are at a turning point in how enterprises embrace change, manage disruption and deliver new services with pace. Point tools for automation are inadequate against this challenge. AUTOMIC’s approach through a unified business automation platform, One Automation, allows seamless integration from the business processes through the IT services supporting those processes and the delivery of applications to differentiate the business. AUTOMIC empowers businesses through automation – end to end.”

Since one of the primary goals of DevOps is efficiency it makes sense to combine tools into a unified platform. Giving DevOps teams a single, consistent interface to manage multiple facets of DevOps automation seems like a logical solution.

I have a couple issues with the AUTOMIC offering, though. First, I’m not entirely sure what it’s actually called. AUTOMIC uses Continuous Everything—capitalized as if it’s a proper name—but it also states that the AUTOMIC Business Automation platform delivers three levels of DevOps automation, and DeLaughter refers to One Automation. When all is said and done, I’m not really sure if AUTOMIC is referring to three different tools or just has three different names it uses to refer to the same platform.

The second issue I have is the use of the word “everything” for an automation solution that only covers three things. There is a wide variety of continuous automation solutions for DevOps: continuous delivery, continuous deployment, continuous improvement, continuous integration, continuous monitoring, continuous testing, and more. Providing continuous delivery, continuous operations, and continuous services in a unified platform is ostensibly better than delivering just one or two of those options, but it’s far short of being “everything”.

The names become an issue again when you try to buy the tools. They aren’t actually called continuous delivery, continuous operations, or continuous services. There is AUTOMIC Release Automation, AUTOMIC Workload Automation, and AUTOMIC Service Orchestration, which are each plugins that work with the AUTOMIC platform. All plugins are immediately available on the AUTOMIC Marketplace. Pricing is available on-demand.

November 18, 2015
In-App Messaging: The Key to a Better User Experience
As the mobile device obsession grows, enterprise IT departments are learning the hard way that today’s Web applications, will in fact, not live forever. Enterprise developers are now forced to turn their focus to mobile app development – not just repurposing a Web API for mobile, but embracing what is inherently different about the mobile platform.

Mobile isn’t just a smaller screen size, but for companies, it’s a whole new device for interacting with stakeholders in real-time. With in-app messaging, brands now have a powerful new channel to foster a private conversation between themselves and their customers. Further, companies can leverage data directly from interactions in the app to create more authentic and beneficial messages for the customer.

Using in-app messaging has a big pay-off for brands, too. According to a June 2015 report from app marketing and analytics firm Localytics, apps engaging in messaging have a two to three-and-a-half times higher retention rate and more uses per month than apps not using in-app messaging.

But for even the most experienced enterprise developer, integrating new features in a mobile application can be a tough process. The technical challenges alone can be too much for an in-house IT department, and developers could be stuck scratching their heads due to a lack of replicable use cases. We believe there are three simple steps that a developer can start with to incorporate in-app messaging to help build the foundation for a dramatically improved and far more engaging mobile user experience.
1. The simplest in-app messaging application is using chat as a help feature. Imagine on-demand customer service from the palm of your hand – in store or in the comfort of your home. Think about how direct communication can improve customer experience. Is there a glitch in the app hindering the use of a feature? A question about an in-app purchase or pricing on a product in store that can be answered in the moment? There are many current scenarios that could be supported by using chat as a help feature, but the real possibility is in things that aren’t common today. Picture connecting chat to an in-store server, and joining a real customer service specialist to a customer needing assistance within minutes. Perhaps one day, in-app messaging could replace customer service calls all together.
1. Another great way to utilize in-app messaging is by using chat as a way to share announcements. Instead of focusing on creating a private conversation between just two parties, sharing an announcement via chat is great way to spread communications to a group of people within an app. Share information about an upcoming event or sale, or send a cancellation update immediately (eliminating the frustration from those who didn’t check their email or voicemails!). And think outside of the box – these announcements don’t need to be text string, but rather HTML, JSON or images. Think about this as a push notification, but more personal and intuitive. However, while you may want to share announcements with all users, like a push notification, be aware that these messages can seem less targeted, like getting spammed. Alternatively, use a messaging platform that can sift through backend data to grab the intel required to customize announcements to specific audiences, all on its own.
1. Finally, evolve your messaging a bit further by sharing images or content through chat. Facebook and WeChat are great examples of how to create more context within in-app messaging: share a link using in-app search or send animated emoticons to create sentiment. And again, think beyond a personal conversation, but how to engage a whole group. Perhaps you drop a pin on Google Maps and direct a group to a certain location or share a digital coupon to a set of customers. And while smaller images can be sent as binary payloads across the messaging transport, developers should consider size and performance implications and may want to use a different approach. There are even ways to use a URL in the message payload to transfer any kind of file (including an image!). The key to engaging customers with this feature is with powerful insights: integrate with different workflows and data using an end-to-end tool to deliver meaningful content to individual users.
These use cases could seem like simple additions or advanced ideas depending on the current state of your mobile app, but either way, they’re just the tip of the iceberg.

The ever-evolving mobile world full of consumers seeking cooler, better, faster mobile experiences means one thing for enterprise developers: change. We must move beyond the traditional thinking to consider not only app design, but how users want to interact with their apps, and what value new features add for customers.

Whether you’re starting out with chat as a help feature or shooting for the stars with another intuitive messaging tool on the horizon, it’s safe to say the future of in-app messaging will be transformational for user experience.

About the Author/Shannph Wong

Shannph Wong is the Head of Engineering at Magnet Systems. Magnet Systems is powering the next generation of mobile applications with an open architecture to enable businesses and developers to create more engaging and productive enterprise-class mobile applications.
November 17, 2015
Agile Infrastructure: Because your Infrastructure Deserves Tests, Too
Editor’s Note: This post was updated Aug. 4, 2018, to reflect an updated slide presentation at the end of the article.

Infrastructure as Code is a truly powerful concept whose significance is best described with the words of Adam Jacob, CTO at Chef, in Web Operations: Keeping the Data On Time: “Enable the reconstruction of the business from nothing but a source code repository, an application data backup, and bare metal resources.” And so it’s not for nothing that treating infrastructure as code is regarded a key principle for reducing cycle time and maximizing flow in Continuous Delivery and DevOps, respectively. Even if your plans are less bold as you read this article, wouldn’t you agree that consequent validation of what you automate on the infrastructure level — long before it goes into production — would be extremely powerful?

So, bear with me for a while and please don’t rush head over heels into automation by simply picking one of the established infrastructure automation tools such as Chef or Puppet, getting everyone trained in Ruby, and blindly start to “automate all the things”. If that’s how you do it, then you are most probably doing it wrong. In You’re Doing DevOps Wrong. Automation in the Enterprise., author Alan Sharp-Paul suggests that, before doing any automation, you first have to understand precisely the requirements and how to validate them to gauge success and maintain quality of your automations over time:
- Are the configuration files in place? Do they contain the right settings?
- Is this port open? Is that port closed?
Why Agile Infrastructure?

Honestly, you and I wouldn’t expect anyone to come up with reliable software merely by choosing an arbitrary programming language and a nifty IDE without having some sort of engineering process in place, right? Likewise, the (automated) provisioning of a solid production environment demands a no less methodical approach. Luckily, Infrastructure as Code enables us to treat the provisioning of infrastructure as well as automating deployments and configuration as an Agile engineering discipline. Although the concepts of Agile Infrastructure are not entirely new, testing against live infrastructure has only recently been facilitated with the consolidation of tools such as Ansible, Chef, Puppet, Docker, Vagrant and Serverspec under the hood of Test Kitchen (see more on that below). Here are some of the key implications of applying Agile software development practices to the infrastructure level:

Alignment of Devs and Ops

Agile software development teams are driven by customer demand and aim to produce outcome in short, regular intervals. Enabling IT Operations and Infrastructure departments to work in small iterations and react to changes quickly allows them to align with and effectively become driven by software development. The outcome of these joint efforts will be both working and deployable software at the end of each iteration.

Fail Fast: Feedback Loops

Executing infrastructure tests as part of your Continuous Delivery build pipeline (before an application is deployed and long-running tests are executed) establishes another important feedback loop that enables you to “fail fast” and get the right people involved. The underlying principle is simple: by expressing your intentions twice — once in the code and once in a test — you’ll know you’ve caught a bug whenever these assumptions don’t match.

Regression Safety

Believe it or not: whether you are using Ansible, Chef, Puppet or any other — you’re running on code! Their respective issue lists are full of unresolved issues of various severities with new issues coming in regularly. Having a sufficient safety net of tests for your infrastructure in place allows you to quickly identify bugs as they creep in (from either side) and protects you against unwanted regressions. After all, a bug in your infrastructure can be very hard to track down and can be much more severe than a bug in your application.

Refactoring

Code refactoring becomes a breeze when you have tests in place that immediately alert you when you broke the desired state of your infrastructure (and all you wanted was to make your code simpler and more maintainable). This is invaluable when you want to recompose your existing infrastructure from 3rd-party components offered on public hubs such as Ansible Galaxy, Chef Supermarket or Puppet Forge, and especially when you are migrating away from your existing automation stack.

The Red, Green, Refactor Cycle of Test-Driven Development

Test-Driven Development (TDD) is a popular software development process that involves writing code in short, repeating development cycles with the goal to enforce good design and enhance confidence. While it is certainly no silver bullet and has been controversially discussed in the past, the Red, Green, Refactor Cycle, which is at the heart of TDD and whose principles I want to quickly summarize here, hopefully gives you some inspiration on how to incrementally build up your infrastructure:
1. Red: Understand the requirements and the state you want to implement. Then think about how to capture this state in a test. Implement the test, then run your entire test suite and see the added test fail — and if it doesn’t, something is really wrong.
2. Green: Implement just enough functionality to make the test pass. Don’t care much about readability, simplicity and design for now — just make it work. Run your tests again and watch all tests pass. If they don’t, either fix your test or your implementation, or take a step back (revert to a point in your code that’s known to work) and start over with a smaller increment.
3. Refactor: Now that your tests pass, improve your implementation and make sure, by running your tests again, that you didn’t break anything. Once you are done refactoring, start the cycle over again.
Keep in mind that each repetition of the cycle refers to a small increment. In terms of infrastructure, such an increment could be the installation of a user, a package or the placement of a configuration setting. When you arrive in a spot where you broke something, you can easily revert to a point in your code that’s known to work. Leveraging such practices really makes the difference between Infrastructure Automation and Infrastructure as Code, as described in Infrastructure as Code – Automation Is Not Enough by Keith Morris.

Test Kitchen, Terraform, AWS and awspec

Now, how to get there? Test Kitchen is an easily extensible test harness that allows you to test your code written in Ansible, Chef, Puppet (and others) on various cloud providers, virtualization providers and operating systems with tests written in a variety of test frameworks.

In the following presentation, I give hands-on examples for you to quickly dive into the topic of using Test Kitchen with awspec as a framework to test Terraform deployments on AWS:
November 13, 2015
APM on-premises or SaaS: What’s the best fit?

Today’s DevOps teams need in-depth monitoring that offers insights into every aspect of the application-delivery chain. When you decide for an application performance monitoring (APM) solution, you can choose between an on-premises approach or SaaS-based solutions (“Monitoring as a Service”). Every deployment option brings its pros and cons or has advantages for special use cases. An installation on-premises for example works best if you want to monitor an intranet that you want to keep isolated.

Which APM deployment option makes most sense for your organization? There‘s no simple answer to this question. A lot depends on your environment and requirements. Let’s explore the points to consider in deciding between SaaS and on-premises monitoring:

Server location

With in-house, on-premises systems, all servers and data are physically under your control. When you use SaaS-based monitoring, performance metrics, reliability data, and detected issues are stored in the cloud. If your industry has strong regulatory and policy requirements, SaaS may not be an option for your organization—you may need to keep all such monitoring data on-premises.

Implementation

To deploy on-premises solutions you need to provide your own hardware and storage in a private datacenter or cloud. You install and configure the monitoring software, databases, and other components of the APM solution. In general, SaaS offerings can be installed and set up within minutes using a self-service system. Some SaaS APM tools even auto-detect your entire server landscape within minutes following installation.

Software updates

SaaS solutions are typically updated automatically on a frequent basis by the vendors who provide them to deliver support for new technologies and feature enhancements. On-premises installations require that you manage updates yourself and stay current with the release of new product updates. Updates for on-premises solutions typically come out less frequently, which means you sometimes have to wait longer for support of new technologies and bug fixes.

Server and database backups

Maintaining your own servers for an on-premises APM solution requires that you manage the servers, data storage, and data backups yourself. SaaS solutions are maintained and backed up by their vendors.

Costs

On-premises software is usually licensed for longer periods of time. This means that the initial investment is often higher, but costs are recouped over time. SaaS-based APM often features “pay as you go” pricing, so you only pay for what you use. This model can be cheaper, but it depends heavily on your usage and your tool vendor’s pricing model. If you run extra servers during periods of peak demand, it makes a big difference if your billing is based on the maximum number of servers you use rather than your actual usage. Because they’re built on cloud infrastructure and often don’t require long-term contracts, SaaS make it much easier for you to opt out of the system and cancel any time. As you aren’t required to purchase and maintain your own hardware, they’re also typically more flexible and easier to scale.

Support

When your monitoring solution runs on-premises it’s often harder to get vendor support because the system may not be reachable from outside your organization. With SaaS-based solutions you can grant access to your tool vendor’s support staff and work with them on resolving issues. This makes the SaaS approach faster and easier if you run into special cases that require vendor support.

Mobility

With on-premises solutions you must connect to your internal network via VPN to view monitoring data on mobile devices (unless your organization exposes this service to the Internet). Conversely, you can access monitoring data supplied from a SaaS-based solution anywhere you have an Internet connection.

Customization

With an on-premises APM solution, you can expect in-depth customizations that suit the exact requirements of your organization. Customization of SaaS solutions on the other hand is limited, and dictated by rules defined by your tool vendor.

Distributed applications

If you need to monitor applications that run in a public or hybrid cloud scenario, it’s likely that you’ll also want to run your monitoring in the cloud. SaaS-based solutions enable you to seamlessly monitor cloud-based environments because this is what they’re designed to do. You only need to install agent software on the involved servers.

(No) single point of failure

On-premises solutions are vulnerable to critical problems like power outages and broken network connections, potentially leaving you with no way of receiving performance and availability problem alerts. On the other hand, SaaS monitoring in the cloud runs in a different geographical location and so remains available to send you alerts whenever problems are detected.

Reliability and redundancy

When your APM monitoring solution runs in your own data center, your IT department can determine appropriate service availability levels. SaaS monitoring providers often use software architectures that can be updated without downtime and reach service availability levels of up to 100%. Well-designed SaaS solutions use redundancy to further improve availability. It’s recommended that you take a close look at any SaaS-based solution vendor’s claim of providing “always on” availability.

Scalability

SaaS tool vendors ensure that needed resources like disk space and CPU will scale up with your demand. This means you won’t need to budget for additional hardware purchases and typically leads to lower total cost of ownership (TCO) with cloud-based SaaS solutions.

Conclusion

Deploying monitoring software in house (on-premises) gives you full control over your data. “Monitoring as a Service” in the cloud brings new possibilities for many monitoring use cases. Depending on your requirements, it could even make sense to use both. Some tool vendors are now providing monitoring solutions that combine the best of both worlds.

With the points covered in this article, you should now know everything you need to consider when deciding which monitoring approach makes most sense for your organization.

November 11, 2015
9 more open source DevOps tools we love
A while back we ran an article by Tomer Levy of Logz.io about 9 open source DevOps Tools that we loved. Of course how can you pick just 9 among so many worthy choices? So we wanted to revisit the open source DevOps tools space and add another 9 tools to the list. In a few months we will be adding more open source DevOps Tools to the list as well. In the meantime here are 9 more must have open source DevOps Tools that we love:

1. Kubernetes is an open source orchestration system for Docker containers. It handles scheduling onto nodes in a compute cluster and actively manages workloads to ensure that their state matches the users declared intentions. Using the concepts of “labels” and “pods”, it groups the containers which make up an application into logical units for easy management and discovery.Originally developed and owned by Google,Kubernetes was offered to the Cloud Native Computing Foundation to seed other complementary technologies to enable a set of common container technologies. It is an integral part of CoreOS’s Tectonic product, in addition to being tightly coupled with Mesos and the Mesosphere DCOS.Kubernetes offers the promise of Google-like container usage for everyone. It seems no matter what the basic container technology we use, it is being used with many of the container-based PaaS stacks today

2. Chef – From the official what is: “Chef is a systems and cloud infrastructure automation framework that makes it easy to deploy servers and applications to any physical, virtual, or cloud location, no matter the size of the infrastructure. Each organization is comprised of one (or more) workstations, a single server, and every node that will be configured and maintained by the chef-client. Cookbooks (and recipes) are used to tell the chef-client how each node in your organization should be configured. The chef-client (which is installed on every node) does the actual configuration.

More than the above though, for many Chef along with Puppet Labs and Jenkins are the heart and soul of DevOps tools. Moving beyond its original configuration management mission today Chef represents the move to “everything as code” while still maintaining its open source commitment. Chef Delivery, Chef Compliance move Chef into the realm of a tool that is involved in the entire DevOps workflow.

3. Puppet – The Romulus to Chef’s Remus, Puppet Labs is one of the founding members of the DevOps movement. Built on open source and still fully supporting its open source heritage going forward, Puppet like Chef has moved beyond its original mission of configuration management and automation of single machines or instances to orchestration of your entire stack.

From Puppet’s open source doc, Why Puppet

Puppet has been developed to help the sysadmin community move to building and sharing mature tools that avoid the duplication of everyone solving the same problem. It does so in two ways:
- It provides a powerful framework to simplify the majority of the technical tasks that sysadmins need to perform
- The sysadmin work is written as code in Puppet’s custom language which is shareable just like any other code.
This means that your work as a sysadmin can get done much faster, because you can have Puppet handle most or all of the details, and you can download code from other sysadmins to help you get done even faster. The majority of Puppet implementations use at least one or two modules developed by someone else, and there are already hundreds of modules developed and shared by the community.

4. Maven – a Yiddish word meaning accumulator of knowledge, Maven was originally started as an attempt to simplify the build processes in the Jakarta Turbine project. There were several projects each with their own Ant build files that were all slightly different and JARs were checked into CVS. We wanted a standard way to build the projects, a clear definition of what the project consisted of, an easy way to publish project information and a way to share JARs across several projects.

The result is a tool that can now be used for building and managing any Java-based project. We hope that we have created something that will make the day-to-day work of Java developers easier and generally help with the comprehension of any Java-based project.
Maven’s primary goal is to allow a developer to comprehend the complete state of a development effort in the shortest period of time. In order to attain this goal there are several areas of concern that Maven attempts to deal with:
- Making the build process easy
- Providing a uniform build system
- Providing quality project information
- Providing guidelines for best practices development
- Allowing transparent migration to new features
5. Gradle – the yin to Maven’s yang, Gradle and Maven are much like Puppet and Chef. In this case though Gradle was born out of frustration with Maven and other tools. From the Gradle, Inc. site:

Gradle was founded by Hans Dockter who was working in Enterprise software development and ran into an intractable build problem. At the time he was using Apache Maven. After three days and nights of exhaustive research, he discovered that the problem could not be fixed with the tool at all. Hans vowed to cure this problem for himself, for his team, his company, and for developers everywhere. He was joined in this mission by founder CTO Adam Murdoch. After releasing Gradle the open source project out into the wild in April of 2008, Hans and Adam then hired all of the key contributors whom they met along the way. These included world renown Gradle experts from companies like Thoughtworks, Typesafe, and Pivotal.

Many developers and shops today use one or the other of these open source tools.

6. Mattermost (& Zulip) Today is all about ChatOps. In many organizations it is replacing email as the primary communication method between teams and even outside members now. While there are plenty of commercial solutions in this space like HipChat and Slack, there are some worthy open source tools available as well. One of the biggest advantages to these open source solutions is you don’t have to use a hosted version if you are worried about control, governance or security issues. You can install these on your own server and maintain yourself if that is your preference. Here are two of the leading open source ChatOps tools:

Mattermost – is an open source Slack alternative. The company behind it is a Y Combinator funded startup with founders who come from Microsoft Office engineering. Frustrated that in using a SaaS hosted chat program they were locked out of their own data unless they paid to use the app they set out to create their own self-hosted app and so Mattermost was born. Not sure where the commercial element ill join this, perhaps open core type premium features? Support? Time will tell.

Zulip – Acquired and then released as open source under an Apache license by DropBox, Zulip is a modern take on ChatOps. Not based on IRC and XMPP, Zulip features: Threaded group conversations, One-on-one and group private conversations, Persistence, History, Full-history search, Team presence and buddy list, Inline image, video, and tweet previews, Drag-and-drop file uploads, Stream-wide announcements, Emails for important missed messages, Desktop notifications, Audible notifications, Hotkeys, Emoji, Code, Lightweight markup, Message editing, Invite-only streams, Starred messages, Integrations, API, Mobile apps, Desktop apps

7. OWASP – A developers and DevOps best security friend, OWASP has become the place for web application security. Their mission is to make software security visible, so that individuals and organizations worldwide can make informed decisions about true software security risks. OWASP is actually an umbrella for a number of different projects including tools, lists (OWASP top 10) and groups. Their website says it best:

The OWASP Foundation came online on December 1st 2001 it was established as a not-for-profit charitable organization in the United States on April 21, 2004 to ensure the ongoing availability and support for our work at OWASP. OWASP is an international organization and the OWASP Foundation supports OWASP efforts around the world. OWASP is an open community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted. All of the OWASP tools, documents, forums, and chapters are free and open to anyone interested in improving application security. We advocate approaching application security as a people, process, and technology problem because the most effective approaches to application security include improvements in all of these areas. We can be found at www.owasp.org.

OWASP is a new kind of organization. Our freedom from commercial pressures allows us to provide unbiased, practical, cost-effective information about application security. OWASP is not affiliated with any technology company, although we support the informed use of commercial security technology. Similar to many open-source software projects, OWASP produces many types of materials in a collaborative and open way. The OWASP Foundation is a not-for-profit entity that ensures the project’s long-term success.

8. Zabbix (& Observium) – OK so lots of people have grown to hate Nagios. There are still lot of people who use Nagios too. That being said, we wanted to highlight some open source options in the network and application monitoring space. Two we like are Zabbix and Observium.

Zabbix – The basic work sphere of Zabbix LLC is development of open source software for monitoring of networks and applications. Apart from that the company offers a wide range of professional services designed to fit every customer’s unique business demands including implementation, integration, custom development and consulting services as well as various training programs.

Zabbix team’s mission is to make a superior monitoring solution available and affordable for all.

The company’s flagship product is Zabbix, one of the most popular open source monitoring software in the world. It is already used by a vast number of companies, who have chosen it due to real scalability, high and robust performance, ease of use and extremely low costs of ownership.

Observium – is a low-maintenance auto-discovering network monitoring platform supporting a wide range of device types, platforms and operating systems including Cisco, Windows, Linux, HP, Juniper, Dell, FreeBSD, Brocade, Netscaler, NetApp and many more. Observium focuses on providing a beautiful and powerful yet simple and intuitive interface to the health and status of your network.

Professionally developed and maintained by a team of experienced network engineers and systems administrators, Observium is a platform designed and built by its users. Observium Community is available free to everyone and recieves updates and features twice annually. Observium Professional adds priority access to daily updates and new features for a small yearly fee.

9. Cucumber – OK raise your hand if you use Cucumber. It is one of the best kept secrets in the business. I am constantly amazed out how many developers and DevOps folks mention this open source tool. It’s actually several tools as their are different versions for different languages with each one having a slightly different feature set.

For those of you who don’t know, “Cucumber has revolutionalized the software development lifecycle by melding requirements, automated testing and documentation into a cohesive one: Plain text executable specifications that validate the software.”

So those are our latest 9 open source DevOps tools we love. We know there are more. Leave comments with worthy choices for our next article.
November 9, 2015
Ancestry.com Brings BlazeMeter into the Fold

In order to gather and organize your lineage and the branches in your family tree, Ancestry has spent more than a generation (the company was born in 1983) wading through the 16B+ images and records buried in historical society data, government archives, and information caches of like organizations, groups, and communities the world over.

Data in hand, Ancestry transcribed it and converted it into a searchable format for your investigation so you can connect the dots from great, great aunt Tildy to great, great, great grandpa Jebediah. “These historical records date back to the 11th century and form more than 30K collections that include birth, marriage, and death records as well as military service, immigration, and even incarceration records,” says Norman Warren of the Ancestry Performance Team, Ancestry.

Ancestry’s platforms enable it to unite descendants and the curious with true tales from 70M family trees that subscribers build up by adding their own branches. Interestingly, Ancestry data now relies on a million plus DNA samples and counting.

“Our servers respond to more than 75M searches per day,” says Warren, who coaches Ancestry’s teams in refining load testing practices as they release new testing scripts before and after sprints and based on their individual development timing.

Load Testing Before & After

When the Ancestry team went looking for deeper, broader load testing capabilities, they were hoping to add routine testing across the site 365-days a year. The folks at Ancestry wanted a malleable solution that would invite them to apply JMeter to vertical load testing and permit them to cut costs for load testing by leveraging the advantages of open source testing tools.

Ancestry had been using a load testing approach that did not allow Warren’s teams to use home-brewed scripts. But in order to benefit from a testing solution that did embrace such scripts, Ancestry had to ensure a flow of updated quality scripts from every applicable internal group. Because Ancestry ultimately opted for JMeter and BlazeMeter, that presented challenges such as JMeter and BlazeMeter learning curves, the need for users to make JMeter requests in parallel, and Ancestry apps that are harder to script.

Growing pains accompanied BlazeMeter adoption including the pains of stretching to embrace different devops teams in order to retrieve testing scripts. By pointing out the advantages of the new testing paradigm, making the argument for time saved by site wide load testing, and providing training in JMeter, Ancestry made the leap to the BlazeMeter supported approach. “BlazeMeter provided excellent JMeter training while we evangelized for teams to own their scripts,” says Warren.

Ancestry solved its technical and learning curve challenges with steps including installing the JMeter Webdriver Set plugin and learning to debug and test scripts before they would run optimally in the BlazeMeter cloud service.

“We had to work to get adoption, but it was well worth the effort to build accountability over different sections of the site. We now ask teams to take ownership of their own scripts to review, modify, or emulate user traffic flows,” says Warren.

Results

“BlazeMeter enabled more frequent load testing at a competitive cost and good site-wide load testing with the ability to add loads to stacks or to stop loads on one of the stacks during the test,” says Warren.

BlazeMeter helped the Ancestry teams to foster a strong confidence that they could support heavy traffic loads at their most hectic times. “The BlazeMeter team helped us to translate the metrics we use for measuring traffic into a number of concurrent users for loading the site. In this way, BlazeMeter helped us to measure load test results against a baseline, such as traffic on our most recently busiest day,” says Warren.

Ancestry leveraged BlazeMeter’s swift feedback about site throughput and the response times of each page to speed site responsiveness for each user. Ancestry was able to predict and automate the flows that are most commonly used by customers in order to streamline processes and speed the user experience even more.

“We created a new baseline from new site wide load tests of additional traffic flows by loading flows incrementally using a special BlazeMeter feature that enables us to dynamically add more concurrent users in the midst of a load test,” explains Warren.

November 6, 2015
Testing Nightmares: Real-Life Frightening QA Experiences

In the spirit of Halloween, this past month testing experts from around the globe answered the call to join in a “crowd-sourced” article highlighting their most frightening testing QA experiences. These are real-life examples of testing gone wrong—leading to all sorts of mayhem in some cases. We allowed these testers to hide their identity, and to keep their organizations anonymous to solicit the most behind-the-scenes responses.

In no particular order here are the top five Testing Nightmares, as told by the testers themselves:

The Importance Of Making Sure Your Hosting Company Gets Paid

By Ivar (from a medium sized company/ now acquired)

The company I was working for at the time had bet its existence on signing an enterprise contract that it had already been in negotiations for more than year with. We were building a digital asset management system that controlled the licensing and delivery of assets to corporate devices. (Think ‘private app store’.) I had written backup tooling that wasn’t ready for use but was included, unused, in the branch that was being deployed. Ten minutes after the final deployment (in preparation for client review!) all of our assets disappeared. Nothing new in the deployment was related to asset storage except my code. There was an eight-figure contract on the line and we had no backups. Fueled by the mother of adrenaline rushes, I reviewed my work and remained convinced that my code was not the cause of the loss. I was already into investigating other possible causes when another developer informed our team that after calling our asset host, he discovered that we had neglected to update our billing credit card. The host had turned off access to all of our assets ‘to get our attention’. They succeeded, but at oh what a price…

Not The Best Way To Start As The New Test Automation Engineer

By James Eisenhauer

This happened my first week as the new and only Quality Engineer at a health and wellness startup. I was on a mission to get test automation created and show them what I could do for them! My first test was to invite all the members of a test company to a new company wellness challenge. It just so happened the company President’s test account was a member of that test company. I scheduled my tests to run at 5 a.m. At 5:38 a.m. we all received an email from the President that read, “Emails every few minutes telling me that QA wants me to walk by the damn river. Make it stop!” “Walk by the River” was a copy of a real wellness challenge we had in our test system. Something in my auto-retry logic had gone horribly wrong. First impressions are a bitch!

Gaming Fail

By Abe Chiu

While working for a gaming app company, we pushed out a build with an engine update that reverted all of our users back to levels that were saved on their device. This as opposed to the one that was saved on our server side. (Example: If logged in to create an ID and was at level 50 on your device, that was the save that popped up even though on our server you had previously reached level 125). All of our users were affected. That’s not the worst part. Some of our users reverted back to level 1 when they were above level 100 and up. This all happened on a Friday and the build was pushed on Thursday night. On Friday we were only able to fix some issues with a small percentage of our user base but the ones that were reverted back to level 1, those were not able to be helped until the following Monday.

The White Screen of Death

By Anonymous

I work as a Software Engineer in test at a media company. This company has its own video player that is embedded either as a single standalone video or a playlist. The player was re-done completely, and I was responsible for testing it before it went out to production. I tested the player as a single video and found a number of issues so the release to production was pushed out. After the issues had been fixed, I tested it again as a video and then gave my “go-ahead” to release it to production. The problem was I had COMPLETELY FORGOTTEN to test the playlist! We had figured that everything looked good and since the release had already been pushed off once, we made a decision to release it to production at the end of the day, around 5:30 p.m. I double-checked it on production as a single video and it looked fine. An hour later, when I got home, we started receiving urgent messages and emails that the playlist wasn’t working!!! You could only watch the first video and then it became a blank white screen! Since the playlists are embedded so deeply, this was a major problem. At 6:30 pm that night only one engineer was around and online but he wasn’t sure how to revert it. Finally after a very stressful hour and a half, he figured out how to do it and I verified that everything was back and working again with the old player. I still can’t believe that I had forgotten to test the playlists, which is such an important part of the feature.

Global Communication Breakdown

By Joe Nolan

We were trying to create a mobile on-line conferencing feature to include in our education app, much like Google Hangouts. Testing had gone well in controlled environments. Then we pulled all of the teams together to have a large group call using and testing the feature. We immediately had reports of crashes and all sorts of issues. It was impossible to talk over the people trying to diagnose the problems, while at the same time others were randomly pushing buttons to try the feature. Even worse, participants were located around the world with different networks and connectivity issues. It was worse than herding cats!

About the Author/Sauce Labs

Sauce Labs is the leading cloud-based web and mobile application automated testing platform. Its secure and reliable testing infrastructure enables users to run JavaScript unit and functional tests written with Selenium and Appium, eliminating the time and expense of maintaining a test grid. With Sauce Labs, organizations can achieve success with continuous integration and delivery, increase developer productivity, and reduce infrastructure costs for software teams of all sizes.

October 29, 2015
Continuous test and monitoring essentials for SDN and NFV
The prior blog Continuous Test Monitoring DevOps Healthbeat discussed the importance and suggested practices for testing and monitoring test trends. This need is amplified when the system that is being tested and monitored is a network of co-operating applications, infrastructures and devices such as networked components of next generation Software Defined Networks (SDN) and Network Function Virtualization (NFV) systems. In networked systems a problem with any network component such as end-user applications, network interface devices, network control plane, network data plane, load balancers, firewalls, network administration, orchestration, and network virtual infrastructures can seriously impact user and network services performance. The number, variety, topology and versions of components and their host environments present special challenges for DevOps continuous testing and monitoring.
In an SDN and NFV world all production topologies and network variations must be tested and results must be monitored or the results will be uncertain. Despite the complexity, or perhaps because of it, continuous testing and monitoring must be optimized to ensure that testing and results analysis for each CI/CT cycle keep pace with accelerated continuous testing and longer term continuous test monitoring is necessary to assure overall delivery confidence for each release and longer term product performance trend in a positive direction. Individual test results or a fixed number of test campaigns can only tell you so much.

Unless the results of testing and test analysis are continuously monitored and results aggregated over multiple test and release cycles for all network nodes and all topologies then there is no way to build sufficient sustainable confidence in the long term health of the SDN network and NFV components. The combination of topology-aware continuous testing solutions together with continuous test monitoring tools that can aggregate results over the entire set of network resource can provide a longer term strategic view of test results that is necessary to collect, aggregate and organize test results data to gain confidence in network components and services for each release and evolution over multiple releases.

Below are some suggestions in a checklist format that have proven useful for continuous testing and monitoring for sustainable high performance SDN and NFV systems and services.
1. Determine continuous testing and monitoring priorities: Some examples of problems that continuous testing and monitoring can help with include intermittent failures caused by the virtual network infrastructures, virtual network functions, network administration, orchestration and management, 3rd party network and end-user systems compatibility, network performance, network fault-tolerance features. The best practice for continuous testing and monitoring indicates that the problems of most concern to a specific network system or service will be tested and result trends will be monitored.
2. Regression test network systems and services even though there were no expected changes: Unintended consequences of indirect changes may impact performance so automated regression suites should audit all production network test topologies and version variations areas occasionally just to be sure. Typical examples that are often caught by this are features important to audit functions, system backwards compatibility features and upgrade/downgrade administration features.
3. Select continuous test and monitoring tools that collect and report trends:
  Tools that can correlate and report test results across multiple network nodes and topology variations can find intermittent bugs or problem trends. Thresholds and email alerts and dashboards that highlight short term results views from long term results views are especially valuable.
4. Use continuous test monitoring results to diagnose and resolve problems:
  Intermittent failures and problems that only become apparent when test results are presented as trends over a long term trend are easier to diagnose when a large data set is accumulated and filtered by most probable cause tags. Once a diagnosis is determined, the root cause can be verified through targeted retest cases that set all the conditions in accordance with the diagnosis. Once confirmed then the offending design can be refactored to handle or avoid the failure condition.
The above is a partial list of suggestions for continuous test monitoring that have been proven to support sustainable SDN and NFV network systems and services. At Spirent and Zephyr we think continuous testing and monitoring is critical for successful DevOps. You can hear more about our views on this topic by reviewing our joint webinar at:
Overcoming DevOps Challenges

What do you think of these suggestions and do you have others that should be mentioned?

About The Authors ⁄ Marc Hornbeek & Sanjay Zalavadia

Marc Hornbeek is Sr. Solutions Architect of DevOps continuous test solutions at Spirent Communications, Infrastructure Test Optimization (ITO) BU. He recently managed DevOps at Spirent. He has performed as the primary architect of test automation tools and champion of test automation for firms ranging from start-ups to large multi-national companies. He published more than 30 articles and has been a speaker at numerous conferences and user forums primarily regarding topics related to continuous automated testing and DevOps.

Sanjay Zalavadia is responsible for driving custom success at Zephyr. This includes training, consulting, customer support and client management. Most recently, as the Associate Vice President for Patni Computers Telecoms IT Managed Services Practice, he established IT Operations teams supporting mobile content providers. Sanjay brings more than 15 years of leadership experience in IT and Technical Support Services teams across multiple geographies for both large and small companies. Sanjay has a graduate degree from the Manipal Institute of Technology in India
October 28, 2015