devopsy.kinsta.cloud

Category: Features

DevOps: Build a Continuous Improvement Culture

DevOps was built around the concept of continuous everything. We even use it in many of the names—continuous delivery (CD), continuous testing, continuous integration (CI)—and it is a worthy goal to want to improve the places that form bottlenecks in your software delivery systems and processes.

But what about the bottlenecks in the DevOps systems and processes?

Like any other system, DevOps involves tools. We choose those tools, invest in learning those tools and use them to do great things. But then we have investment in the tool. If our knowledge and systems for deployment are all based around CD tool X or ARA tool Y, we are just as unlikely to want to move from it as we were unlikely to want to move away from the previous toolset.

Even if you discount the number of shops that have done pilot or small-team DevOps but kept the core of their business waterfalling, there are still a large number of organizations that stepped into DevOps and stopped improving. Granted, it is a huge job to move a significantly sized application portfolio into the DevOps mold and toolchain, but it is contrary to the process/goals to stop just because you did.

The market is nowhere near finished evolving: New tools are coming available and massive improvements to existing tools are being released. Keep taking advantage of those facts.

The more projects/portfolios you have moved into DevOps, the more weight there is to resist change. That is the simple reality, just as the larger a rock, the harder it is to move (assuming the same type of rock, of course). The answer: Watch for those improvements that will make moving the rock worth the force required to do so.

Working containers into the overall DevOps process, for example, can benefit every step in the toolchain. But if they’re not already in the process, it is a lot of work to get them folded in. I chose this example because for most shops, a little research will show it is well worth the effort. From preconfigured Dev/Test/Prod servers to run-and-done compile instances, containers can make the process more manageable and more agile. The benefits outweigh the costs for most shops.

So keep an eye out. Don’t implement and spend all of your time on the tools you’ve chosen. Stay aware of what is out there, and what is coming. Understand how it would impact the DevOps process and try to pull in those items that fit the environment.

And, as always, keep rocking it. The end goal is to keep the systems up, running and usable. And most of you are doing a great job.

(This, and all blogs, brought to you as much by the geeks behind the scenes as the author and editor.)

— Don Macvittie

July 17, 2018
Thinking About the Future in the Age of Automation

Let’s do a thought experiment.

Let’s imagine a world in which almost all the work required to sustain human life on the planet is performed by intelligent machines. Think about it: All the crops get planted, raised and harvested by robots. Same for livestock. Machines make all the clothing and build all the houses. People and things get transported by driverless vehicles on the ground, over the oceans and in the sky.

Food gets delivered by an AI-controlled fulfillment service that brings groceries right to the front door. Refrigerators and storage cabinets are smart enough to request replenishment when supplies run low. Packaging and containers are IoT devices that integrate easily with refrigerators and storage cabinets. Everything is communicating everywhere all the time.

Power sources are installed and maintained by robotic intelligence, some of which are supervised by a small cadre of humans. Power is delivered by AI, too. Most power is supplied by solar and nuclear energy. Given the high energy yield-to-weight ratio that fossil fuel and biofuel provide, internal combustion engines still power most aircraft.

Humans login to online schools where the curriculum is designed by AI. Lessons are delivered by AI, too, and the teaching AI is equipped with nice, supportive voices. Each lesson is custom designed to the needs and ability of the learner. Progress is monitored minutely and reported back to interested, authorized parties at regular intervals—mom, dad and the university. Some school systems provide community centers where children and teenagers congregate to learn and practice basic social skills.

Everybody’s DNA is registered in the cloud. Medical services are provided online. People are connected directly to a diagnostic cloud via a variety of fitness devices and smart apparel that constantly monitor the patient’s body, including but not limited to heart rate, blood pressure, lung capacity, daily calorie burn and current body fat index. The devices are smart enough to get blood samples painlessly on demand and then do perfunctory analysis in real time. More complex procedures are administered at a medical center staffed by robots expert in a given procedure, from administering a colonoscopy to resetting a broken bone or performing a liver transplant. A few highly educated, highly trained humans staff the medical centers to handle edge cases beyond the capability of current AI/robotic technology.

Economic productivity is almost completely separated from human labor. Intelligent robotics continue to be the most efficient way to fuel the economy. Human purchasing power is determined by a combination of market-driven forces and social support systems. Those few who have the motivation and skills required to participate in the workforce are compensated for their activities. Such work requires a high degree of education, intelligence and creativity to do the inquiry, analysis and synthesis needed to provide economic value. Their compensation is quite luxurious. Those who are not in the workforce are provided with the purchasing power necessary to acquire the goods and services that are needed for a comfortable life. People who have inherited wealth live a life of luxury, too, for as long as they can manipulate their purchasing power to maintain or increase their wealth. Some wealth is still so immense that it’s inexhaustible.

Crime exists in varying degrees, going up and down at predictable levels. All human activity is observable in the public space. Most humans allow parts of their private space to be monitored in exchange for some type of compensation.

Policing data is analyzed continuously to improve crime prediction models. Humans perform law enforcement activities with the help of robotic assistants. The robots confront armed assailants. The humans supervise. Transgressions such as moving violations and drunk driving are rare, as most transportation is driverless. Violent crime still occurs—always has, always will. Persons exhibiting extreme criminal behavior are isolated in prisons that are run by robots who are supervised by well-compensated humans. Administering justice is still a human activity, as is politics.

Warfare continues, but with fewer humans acting as belligerents. Warring states as well as non-state actors assault each other using physical robots that serve as an extension of the combatant. Cyberweaponry is powered by bots, but most weapons are controlled by a human operator. One human can control hundreds of weapons. Some weapons are self-directing, using artificial intelligence that can interpret predefined assault plans and act accordingly.

Governing policy is created by artificial intelligence under the supervision of human oversight. AI creates legislation based on information gathered from data streams. One stream is data provided by analyzing the behavior and condition of the population. The other stream is polling data. Humans increase their purchasing power by participating in frequent polls administered by government agencies. The authenticity of polling data is verified directly against the DNA of the contributor.

The daily activities of most people are to consume content from the internet and play interactive games either with other humans, AI endpoints or a combination of both. Also, most people use shared assets for amusement; for example, riding a motorcycle or skiing at a resort. Some of the shared assets are owned by individuals. Most are owned by multinational corporations.

Movies are still popular. Some movie scripts are created by humans with AI assistants. Most movies are produced by pure AI, according to deep analysis of the past viewing behavior of a wide variety of audiences. Movies that are custom-designed according to the profile of the particular viewer and produced on demand continue to grow in popularity. Most of the actors in the movies are human emulations designed by AI.

Sports such as baseball, football, soccer and basketball struggle for fans as spectatorship grows in the online gaming sector. Online gambling is still popular, as is the lottery. However, participants cannot use standard purchasing power to gamble. Rather, a special recreation token, considered an extreme luxury item, is used. Lottery tickets are available for free—one per person for a monthly drawing. The winner is compensated luxuriously.

The Stuff of Science Fiction? Not Anymore

If you’ve gotten to this point—and I hope you have—you might be thinking that the fully automated world I describe above is pure fantasy, a pipe dream, science fiction. It might be, but let’s go through the items.

First, in terms of agriculture, in 1790 90 percent of the U.S. population was made up of farmers. Today, the number is around 2 percent, yet production far surpasses 1790 levels. How? Automation.

As far as robots making clothing, check out the Jaeger Rapier Weaving Machine: It makes cloth in 45-foot widths. Also, check out the video from the Wall Street Journal that describes using robots to replace garment workers in Bangladesh.

In terms of transportation, it’s not a question of if driverless vehicles will dominate the roadways of the world. Rather, it’s when. Also, IEEE is reporting that crewless container ships are on the horizon. Norway’s Yarla Birkeland is already here.

Flying is already highly automated. Other than takeoff and landing, human crews serve more as a safety backup in case something goes wrong in flight. In the military, attack drones are still manned by remote human crews. But, again, the humans are there more for fail safety than operational purposes. Flying may never become a solely automated undertaking, but keep in mind that it takes only two humans to operate an Airbus a380, which can seat 850 passengers.

Amazon and Walmart are already in the food delivery business. Right now, it’s a safe bet to assume that a human is doing the delivery. But, given the dramatic improvement in delivery robots, how long will it be until that whole process is run by a machine? Also, LG makes a smart refrigerator that provides many of the food provisioning services described above.

Oh yeah, did I mention that China is presently collecting DNA samples, fingerprints, iris scans and blood types of all residents in Xinjiang between the age of 12 and 65? We’re talking millions of people. Granted, China is not a poster child for respecting the privacy of the individual. But, let’s say that here in the United States there was an offer to give anybody an ancestry report for free in exchange for a DNA sample—or, if “free” proved to have little motivational value, the offer was for $100. People sell their blood for a lot less.

Robotic surgery is real. Right now the robot is an assistant to the human. But, as we’ve seen with the progression of other technologies, allowing surgical robots to have increasing degrees of autonomy is only a matter of time.

In case you’re wondering about the real future of warfare, according to an article on the BBC’s website, “As early as 2005 the New York Times reported the Pentagon’s plans to replace soldiers with autonomous robots.” Interested in a high-powered robotic machine gun that can hit a target 1.5 miles away in the dead of night? Check out the Super aEgis II, manufactured by DoDAAM.

I could go on and on, but I won’t, tl;dr and all that. Still, given the current rate of technical achievement, when you look at any of the scenes I described above, it’s not difficult to suppose that everything I imagined is very possible. From where I sit, we’re just not that far away from the endgame: AI and robots replacing most human labor in the economic sphere.

So, what’s the missing link? What’s it going to take to make sure that, as human labor is replaced and never to return, purchasing power is still maintained? The first step, of course, is to have some reasonable articulation of what that path to a positive outcome can look like. Fortunately, there’s a good deal of thinking going on about the topic. I’ll share a reading/viewing list at the end of this article.

But. more importantly, it seems as if no one in government is really talking about the inevitability of the dominance of AI and robotics or the consequences thereof. The powers that be are frightfully ignorant about what’s to come. I have yet to hear the words, “We need to start anticipating the consequences of a highly automated society,” come from the mouth of anyone in government. This needs to change.

It’s a serious issue. Today, the impact has been felt mostly factory workers, here in the United States and worldwide. When it really hits, when all professions are subject to replacement—which some estimate to be within the next five years—the shock will be overwhelming. Then, unless government “gets it,” the best recourse is to own a lot of stock in pharmaceutical and cannabis companies, because most people will need to be anesthetized to their environment to tolerate the social and economic breakdown on the horizon. Or, we can start planning to work toward a future in which ubiquitous automation provides not only a luxurious life for a few but a comfortable life for the rest of the population.

As for me, I wish we were planning.

Read and Listen to More:

Book: “Rise of the Robots,” by Martin Ford

Book: “The War on Normal People,” by Andrew Yang

Video: “Humans Need Not Apply”

Video: “Obsolete by 2030”

Podcast: “Andrew Yang and Sam Harris Discuss Universal Basic Income“

— Bob Reselman

July 9, 2018
Portability Shmortability: Most Applications are Going Nowhere

I’m a huge fan of the idea of taking our super-duper applications and deploying them where it makes most sense. I always have been. Those of us in application development spent forever bemoaning the fact that our applications weren’t all that portable between operating systems. In fact, looking back through the history of computers, you find there has always been one roadblock or another to stop portability.

First there was byte order and instruction set, and we’ve largely overcome those. Internationalization wreaked havoc on us all for a while, and we overcame that. We’re still pretty mightily struggling with OS-dependent things such as windowing systems, but browser-based apps have largely overcome those also. Java takes a lot of heat for a lot of reasons, but it did improve portability of apps written in it. Maybe not “Write once, run anywhere,” as was often claimed—things such as file locations were still OS-specific—but still a lot closer than compilers that were deeply tied to the operating system they ran on. Virtualization and containers have enhanced portability in another dimension, letting the developer take the OS with the app.

We have overcome a ton of issues, and advancing technology has introduced a ton more. Now we have to either choose mobile targets or find a tool we like that can generate code for wildly different mobile systems from a single source. DevOps really isn’t helping with this process—though it will, eventually. By automating the build process, the target will be switchable at the targeting end, meaning our app—given a tool that can multi-target—can be built for whatever mobile platform the cool kids are playing with today, and the ones that are considered “cost of entry” can be generated in the same run.

So far, so good, right? We find problems, we overcome problems, DevOps helps us overcome them faster with a wider selection of outputs …

And then we hit the data.

Vendors in a variety of spaces would love to paint you a picture where it doesn’t matter. It does. The mass of your data, wherever it resides, is a pull like gravity to new application development. And it should be.

Some will try to explain to you that in the age of APIs, it doesn’t matter where the data actually resides: You can get it.

But it really does matter, and this is not Utopia. Even if you ignore the performance implications of data being latency-infested miles away from applications that need to use it non-stop, those APIs are only a viable option if the data can be secured and protected. By definition, an API is an advertisement that whatever data/service it fronts can be found right here. For applications that traditionally are data center apps, it might be possible to expose your customer file or other critical data via API and then lock down access to the API by IP …

But then we quit ignoring the latency problem. If every bit of data an app needs has to flow from San Francisco (or Tokyo, or Bejing, or London, or wherever) to Seattle before the calling app can do what it needs to and then has to be sent off again to Albuquerque (or Rostov, or Madrid, or wherever) the delays will, by definition, be more than they would be if the app sat with the data and had to transfer over a 1GB (or 10GB) connection between servers before sending it to users.

This means most data-heavy apps, no matter the level of agile or DevOps, aren’t likely to move. Vendors with a stake in the process will trot out the one or two customers they convinced to make such a move to tell you how great it is, but performance math and security sense tell you it is only great until things get busy or that exposed API is used by bad actors to vacuum user data.

Some applications have smaller datasets and can move the data with the app. Other applications can be architected not to care where the data is. A few don’t need a database at all. Move these applications to whatever platform makes sense. Make the CD for them retargetable. Most serious business applications rely too much on core data to fall into these categories. And thus, they aren’t moving, unless someone comes up with a viable way to move a ton of data between platforms that is safe and fast and effectively translates where necessary.

So, that’s what we need to see next in the march of portability. We currently have containers that can be run pretty much anywhere and languages that will work on pretty much any platform. We need data tools that can alleviate the current set of non-portability/latency constraints and get data where it is needed, when it is needed, securely.

Unfortunately, I don’t see that happening soon. So addressing the issue, “Where do we target our new application?” will have to start with the question, “Where is the bulk of the data it needs?” At least for now.

Most of you knew that, because you’re living it. I just thought you might have a use for a third-party article about it. Because someday, you will have this conversation with someone who isn’t living it. Enjoy.

— Don Macvittie

June 29, 2018
GitLab Moves to Automate DevOps

GitLab is looking to eliminate the pain of setting up and maintaining DevOps processes by making available an option that automates DevOps processes end to end using a prescriptive approach defined by GitLab.

The latest version of GitLab includes an Auto DevOps option that organizations can employ to automate the building, testing, code-quality scanning, security scanning, license scanning, packaging, performance testing, deploying and monitoring their applications.

GitLab CEO Sid Sijbrandij said the company is now able to make this service available because GitLab 11.0 can now be deployed as a set of more integrated applications running on top of a cluster based on Kubernetes container orchestration software. That support for Kubernetes also makes it easier to deploy GitLab 11.0 in a public cloud or on-premises environment as needed. To facilitate that process, GitLab now includes templates that simplify the spinning up of Kubernetes clusters as needed, Sijbrandij said.

To further its support for Kubernetes, GitLab also decided to start deploying the software it makes available as a cloud service on Google Cloud Platform. Previously, GitLab had been committed to Microsoft Azure. Microsoft recently announced plans to acquire GitHub.

GitLab is all in favor of automating DevOps processes, but doesn’t think organizations should be forced to move everything into a public cloud to achieve that goal, explained Sijbrandij. Organizations can still elect to construct their own DevOps processes using GitLab as they best see fit.

But as interest in DevOps continues to rise, more organizations now would prefer to rely on a set of best practices that are defined to make them much easier to consume, he said.

GitLab 11.0 also adds security scanning capabilities for application built using .Net and Scala programming language in addition to existing support for C, C++, Java, Python, Ruby on Rails, Go and PHP.

In general, Sijbrandij noted that organizations that embrace DevOps usually find themselves trying to manage various islands of automation with mixed success. Auto DevOps is intended to provide a more comprehensive approach that eliminates the friction that often exists between those various islands of automation. Sijbrandij acknowledged that a prescriptive approach may not appeal to every IT organization, but as traditional enterprise IT organizations start to embrace DevOps, many of them prefer a more platform-centric approach that’s easier to both set up and maintain, simply because they lack internal DevOps expertise.

Sijbrandij also noted that as DevOps gains more traction in the enterprise, many of the decisions about what platforms to employ will be driven from the top down. Today, most acquisitions of DevOps tools and practices are driven from the bottom up, which accounts for why there are already so many silos of automation, he said.

Over time many organizations will conclude that the opinionated approach enabled by Auto DevOps will free developers to spend more time on writing code instead of on managing the infrastructure employed to create it, Sijbrandij said. Most traditional enterprise IT organizations today are at least aware they should be employing DevOps practices, they just know exactly what such an effort fully entails.

Thanks to advances in automation, many IT leaders may never know or care what specific DevOps processes are in place. After all, what most of them are primarily interested in how fast the next set of application code is going to be delivered.

— Mike Vizard

June 28, 2018
DOES UK: Nike Applies ‘Just Do It’ Attitude to DevOps
Nike’s DevOps transformation has had a lasting impact on its culture and productivity, while allowing the company to connect with its customer in ways it never could before. Its journey down the path to DevOps was shared at the DevOps Enterprise Summit (DOES UK) 2018, in London.

For a company of its size and success in the current market to take a giant leap of faith and come out even more successful takes incredible courage, hard work and collaboration. But that’s Nike for you: Shoes, apparel or DevOps—it doesn’t make a difference to the company. From day 1, Nike has lived its mantra, “Just Do It!”

Imagine this: You’re a high-level IT employee at a non-technology-focused company with a market value of just over $110 billion. All of a sudden, the newly appointed CEO makes the most significant announcement in recent history of the company, essentially saying, “We are entering a new era of growth and we expect to use technology as our main way of getting closer to the customer.” Pretty crazy, huh?

This was reality for Randy Lyons, a longtime employee at Nike with an extremely strong taste for competition and the opportunity of a lifetime in his hands. Based in the EMEA region, Lyons teamed with global Nike CFO Michelle Power with one goal in mind: to bring customers closer to the products, available at any of their 7,000 branded stores globally, through a digital platform. The aim was to tap into consumers’ need to check our phones before making a purchase. The scale was momentous; arguably, larger than any other company achieving a successful DevOps or Agile transformation before. To pull this off on the scale CEO Mark Parker had intended, a complete culture shift was necessary.

Luckily, the unlikely team shared the motto, “Culture eats strategy for breakfast,” and they were eager for the challenge. To start, they needed to change the self-identity of the IT branch. For too long had the underutilized IT staff heard the narrative that “technology helps the business succeed,” rather than existing as a part of the business. Lyons and Power placed a heavy emphasis on the new role of cross-functional IT teams as an integral part of the company rather than a useful helper. They adopted the hashtag “#OneTeam,” which promoted interaction and alignment of the tech team with all other teams, and showed everyone working for them that they were fully invested and energized in positively changing the culture and structural hierarchy of Nike. Additionally, they sought to point out the impact each person’s work was playing through the lens of the overall strategy. The “How is what I’m working on going to effect the direction of this company?” question versus “What else do you need me to do?” was a significant change—it boosted the overall motivation of the teams to work together and even raised individual production significantly.

However, the transformation was only beginning. Early on Power and Lyons discovered a fundamental flaw in the company they sought to transform: Their employees didn’t feel rewarded for their work. While it might be easy for some companies to blow off this issue in favor of dealing with “bigger” issues, they wanted to promote a company culture that would foster growth and speed, which would not—or could not—happen unless their teams felt beyond satisfied with their workplace environment. So, instead of the annual award ceremony Nike regularly used to reward and congratulate its employees, Lyons and Power decided to implement a simple change they felt would satisfy everyone: They added 15 minutes to the end of their weekly Friday staff meeting to give shout-outs everyone who had performed above expectations on a project. It was awkward at first, Lyons admitted. He also described it as “quite American” (ha ha)! However, this simple idea created a complete culture shift. Suddenly, the tech team was being praised by the supply team, while the supply team was being praised by the sales team, and the sales team was being praised by the tech team. This weekly validation of a job well done turned into more jobs well done!

Ultimately, the agile teams were motivated enough and aligned in such an efficient way that they were able to produce five separate software systems fully integrated into a single one-member profile:
1. com (full selection of products sold in store)
2. Nike app (for a more personalized experience)
3. Sneakers (collection of shoes sold in store)
4. NRC (for running products)
5. NTC (for training products)
These software products were incredibly effective in creating an emotional attachment with the brand and the products. Finally, the goal of getting the customer closer to the product through a digital interface had been achieved. The process to get there wasn’t easy. There were many problems to overcome and many things that changed drastically to allow for a newer and more efficient way of doing things. However, Lyons noted this transformation was the most influential on a personal level for him: Before undertaking this project, he didn’t feel as though he could effectively serve as both a team leader and participant. He could easily take orders and sometimes give them out, but it wasn’t until he partnered with Power that he learned to become a not just a team player, but the best player on his team.

The DevOps journey was a transformational process for both the company and the people involved. Today, “Just Do It” means exponentially more to Nike than just a slogan—it’s a way of adding value and efficiency to business.

This was just one of many of great presentations at this years DevOps Enterprise Summit UK this past week. We will be highlighting others in the days ahead.

— Landon Shimel
June 26, 2018
Splunk Pushes Into the Realm of DevOps

On the heels of its recent acquisition of VictorOps, provider of incident management software, for $120 million, Splunk is gearing up to expand its foothold in DevOps significantly.

Rick Fitz, senior vice president of IT Markets for Splunk, said the provider of widely used operational analytics software in the enterprise sees a significant opportunity to expand its presence across a range of DevOps processes.

Incident management is a natural extension of operational analytics, said Fitz, noting Splunk chose to acquire VictorOps because the investments the company has made in applying machine learning algorithms to monitoring IT events. That approach significantly reduces the number of irrelevant alerts being generated and provides actionable intelligence into potential events that could adversely impact IT operations.

Most IT operations teams suffer from alert fatigue, Fitz noted, and most alerts are ignored because of a lack of context. The combination of Splunk and VictorOps will result in alerts that more precisely identify the root cause of any IT issue, he said, and a better overall “systems of engagement” for IT operations teams in keeping with DevOps principles.

Splunk has been steadily expanding its focus on DevOps. Earlier this year the company announced Splunk Insights for Infrastructure, which IT organizations can host on an Amazon Web Services (AWS) public cloud to monitor IT infrastructure deployed anywhere. The latest versions of Splunk Cloud and Splunk Enterprise also make use of machine learning algorithms on top of a revamped metrics engine that enables IT administrators to monitor everything from CPU speeds and available hard disk space to temperature readings in internet of things (IoT) devices and sensors. Splunk recently also added connectors for Docker and Kubernetes, as well as the Apache Kafka messaging platform for streaming data in real time.

IT operations and cybersecurity teams already rely on Splunk operational analytics software extensively to identify anomalies. By investing in machine learning algorithms and acquiring incident management software, Splunk is moving to turn all the data it analyzes into actionable intelligence, which then could be shared in real time with developers to ensure application availability and optimize application performance.

While adoption of DevOps processes in traditional enterprise IT organizations remains spotty, IT vendors that focus on IT operations such as Splunk have clearly seen the writing on the wall. Fitz noted that investments made in machine learning algorithms, for example, will enable IT operations teams to more respond to changing application requirements with greater agility at a time when the IT environment has become exceedingly complex. That agility is critical for any organization engaged in digital business transformation, Fitz said, because invariably those efforts lead to more applications being deployed.

It’s not clear the degree to which incumbent providers of IT operations software will be able to remain relevant in the age of DevOps. But most of them certainly have the financial resources to at the very least acquire a portfolio of DevOps tools that will enable them to exert a lot more influence than many of them have to date.

— Mike Vizard

June 25, 2018
What Comes after DevOps? Two Possibilities

People have been talking about the “post-DevOps” world since at least 2014. But have we actually arrived in the post-DevOps era? If so, what comes after DevOps? Let’s explore those questions.

The DevOps concept is more than a decade old. DevOps has seen widespread adoption across companies large and small. “DevOps engineer” is now a common job title for tech folks.

At a minimum, these developments mean that DevOps is now very mature and mainstream. They may even signal the end of DevOps, depending on your point of view.

Even though DevOps remains a useful concept, the fact that DevOps is now so mature means it is no longer as novel and dynamic as it once was.

That begs the question: What comes after DevOps? I think there are two distinct possibilities.

A Reaction Against DevOps

One possibility is that we’ll see a backlash against DevOps, and an attempt to replace DevOps processes with alternatives that are designed to do the opposite.

Indeed, there has already been a fair amount of outspoken criticism of DevOps for years. It has mostly remained under the surface.

But in an era when almost everyone is doing DevOps, it seems reasonable to expect that some organizations will find it doesn’t solve their problems after all. Those organizations most likely will return to earlier ways of doing things.

In this scenario, DevOps is unlikely to disappear entirely. But we probably would end up in a hybrid world where software delivery teams mix DevOps principles, tools and practices with those from earlier eras.

DevOps-ifying the Whole Organization

The other main possibility for the post-DevOps world is that we’ll see DevOps extended into more and more parts of the business that are not directly related to the two core areas of DevOps practice, development and operations.

This trend has already been playing out to a certain extent for years. Concepts such as DevSecOps (which extends DevOps into the security realm) and DevQAOps (which integrates Quality Assurance with continuous delivery) have been around for at least several years.

Still, there is room for DevOps concepts to establish deeper roots in areas outside of dev and ops. Most organizations could benefit from doing more DevSecOps, for example. And as I’ve written in the past, even PR, legal and other departments could be integrated more tightly into the software delivery process.

To date, few organizations have sought total DevOps-ification by applying DevOps principles to all business units. But this could be the great innovation of the post-DevOps world. If this scenario plays out, DevOps won’t go away; rather, organizations will double- or triple-down on their investment in DevOps.

— Chris Tozzi

June 21, 2018
Tricentis, QASymphony Merge: The Age of Continuous Testing Is Upon Us

Big news in the world of continuous testing today as continuous testing market leader Tricentis announced it is merging with QASymphony. Tricentis, a leader of continuous testing, is adding QASymphony’s leading testing automation platform to the mix. The full text of the press release is below.

With the worldwide testing market pegged at more than $34 billion, this is a big move in a very big market. Tricentis raised $165 million last year from Insight Venture Partners and has put this money to good use: The QASymphony merger is Tricentis’ latest move. Previously, it acquired Q-Up, in June, and last year acquired Flood IO.

Tricentis’ merger with QASymphony is happening at a time when continuous testing is becoming one of the hottest areas in DevOps. The demand for automated, continuous testing is driving a revolution in the QA market as companies recognize that quality is as important as speed when it comes to deploying new apps. It is a key cog in the modern software factory.

I had a chance to sit down and speak with Tricentis CEO, Sandeep Johri, about today’s announcement, the testing market and what the future may hold. Sandeep, who has previous experience at HP and other large providers, has a great vision of the market and where it is heading as well as the details that escape many “professional manager” CEOs. His hand is firmly on the wheel as he drives Tricentis forward in this space.

Have a listen to our conversation below, and stay tuned—we will update and continue this breaking story as more details emerge.

Tricentis and QASymphony Merge to Drive Innovation in Continuous Testing for Enterprise DevOps

Next Gen platform disrupts the $34B testing services spend and transforms software testing for DevOps

Mountain View, CA— June 20, 2018 — Tricentis and QASymphony announced their agreement to merge under the name of Tricentis. Tricentis’ market-leading Continuous Testing platform has earned the company unanimous “leader” recognition among the top industry analysts. QASymphony is recognized as the industry’s leading test management solution. The combined solution represents the most modern platform for transforming software testing to keep pace with digital transformation.

“Tricentis and QASymphony are both recognized for their innovative testing solutions,” explained Sandeep Johri, CEO of Tricentis. “Tricentis is known for helping enterprises transform testing from a burdensome manual process that delays software delivery into an automated, continuous process that drives ‘quality at speed.’ The addition of QASymphony’s test management solution strengthens our leadership position and builds on our momentum replacing legacy testing tools.”

“Today’s CIOs are responsible for ramping up innovation through accelerated software delivery,” explained Barry Libenson, Global Chief Information Officer at Experian. “Amid this demand for rapid innovation, CIOs are recognizing that software testing often delays their digital transformation goals. In fact, testing is now commonly cited as the #1 bottleneck to delivery speed. When testing lags behind development, the organization is forced to delay their innovation and that’s no longer an option. It’s inevitable that software testing must be transformed to keep pace with Agile development and DevOps.”

“Global 2000 organizations remain locked into legacy testing platforms that were designed decades ago to enable manual testing processes,” explained Dave Keil, CEO of QASymphony. “Scaled agile and enterprise DevOps initiatives have changed the game. Yet, legacy testing technologies such as those by HPE (now Micro Focus) and CA are throttling speed and innovation. QASymphony has experienced triple-digit growth over the past year—allowing us to aggressively invest in our technology, infrastructure and people to meet the emerging needs of our customers.”

QASymphony’s 100+ employees will be joining Tricentis’ 450+ employees. Sandeep Johri will lead the organization as CEO and Dave Keil will assume the role of COO. The combined company will have a global presence with offices in the US, EMEA and Asia. The transaction is expected to close within 90 days. EMBARGO UNTIL WEDNESDAY, JUNE 20, 2018 @ 8:00 AM ET USA

The integration will reflect the commitment to innovation and customer success that both companies share—to learn more, register for the upcoming webinar. Additionally, the company will be showcasing the roadmap and solution at Accelerate 2018 in Vienna.

DevOps Impact

The market for software testing (recently estimated at $34 billion)1 has reached an inflection point. DevOps adoption is rising rapidly, and both Gartner and Forrester report that transforming testing is a primary factor for DevOps success.2 Yet, software testing remains a predominantly manual activity that delays releases and consumes 30-40 percent of an organization’s application budget3,4 Tricentis Continuous Testing solutions accelerate delivery and free up significant budget that can be reallocated to underfunded innovation initiatives.

Gartner’s Joachim Herschmann and Thomas Murphy report: “As DevOps principles gain significant traction in enterprises, testing and QA is no longer a stage in delivery but an integral DevOps activity that exists in various forms through all areas. Automation has become an indispensable element in these efforts, and there has been renewed focus on software test automation tools as part of a larger toolchain that enables DevOps.”5

About Tricentis

With the industry’s No. 1 Continuous Testing platform, Tricentis is recognized for reinventing software testing for DevOps. Through risk-based testing, scriptless end-to-end test automation, and the industry’s most extensive technology support, Tricentis breaks through the barriers experienced with conventional software testing methods. Our innovative technologies simplify testing for even the most complex enterprise applications—transforming testing from a roadblock to a catalyst for innovation. The result is accelerated software delivery speed, improved cost efficiency, and reduced business risk.

Tricentis is the only vendor to achieve “leader” status in all three top analyst reports (i.e., the “Triple Crown.”) This honor is based on our technical leadership, innovation, and a Global 2000 customer base of 800+ companies, including global enterprises such as Allianz, ANZ Bank, Experian, First Data, HSBC, Lexmark, Merck, Sentry Insurance, Starbucks, Telstra, UBS, Vantiv (now WorldPay), Vodafone, and Whole Foods. These customers rely on Tricentis to achieve and sustain test automation rates of over 90 percent—increasing risk coverage while accelerating testing to keep pace with Agile and DevOps. EMBARGO UNTIL WEDNESDAY, JUNE 20, 2018 @ 8:00 AM ET USA

Tricentis has a global presence in Austria, Australia, Belgium, Denmark, Germany, India, Netherlands, Singapore, Switzerland, Poland, United States and the UK. To learn more, visit https://www.tricentis.com or follow us on LinkedIn, Twitter, and Facebook.

About QASymphony

QASymphony accelerates digital transformation with software testing solutions that help enterprises prioritize quality, develop reliable software and increase speed to market. The qTest platform streamlines software testing in agile and DevOps environments and centralizes testing efforts across the enterprise. By taking a strategic approach to quality, QASymphony enables enterprises to develop higher-quality software, faster, to better support new business models and customer experiences.

The qTest platform streamlines development workflows by seamlessly integrating testing with leading automation, development and delivery tools including Atlassian’s Jira, CA Agile Central, Github, Selenium, Cucumber, Jenkins and many more. QASymphony is trusted by leading enterprises including Forcepoint, PFSweb, Cisco, Samsung, Verizon and Office Depot.

1 Nelson Hall, https://research.nelson-hall.com/sourcing-expertise/it-services/software-testing/

2 Gartner, Build Continuous Quality Into Your DevOps Toolchains: https://www.gartner.com/doc/3868367/build-continuous-quality-devops-toolchains

3 Capgemini, HPE, Sogeti, World Quality Report: https://www.capgemini.com/service/world-quality-report-2017-18/

4 Capgemini, HPE, Sogeti, World Quality Report: https://www.capgemini.com/service/world-quality-report-2017-18/

5 Gartner, Magic Quadrant for Software Test Automation: https://www.gartner.com/doc/3830082/magic-quadrant-software-test-automation

Media Contact

Victoria Brown, Revere

+1 (650) 850-2009

Victoria.brown@revereagency.co

QASymphony Contact Information Kira Mondrus

QASymphony +1 (844) 798-4386 Kiramondrus@qasymphony.com

Tricentis Contact Information

Noel Wurst, Tricentis +1 (904) 673-4427 n.wurst@tricentis.com

— Alan Shimel

June 20, 2018
DevOps: The Things We Must Stop

Anytime there is a popular movement in technology (and I would argue any other field), people get carried away. We’ve seen it over and over, and DevOps attracts this kind of attention. In fact, DevOps caters to those who get carried away by mainstream folks screaming, “THIS CHANGES EVERYTHING!” That type of hyperbole pushes those who get carried away even further. And marketing always takes things to whatever place they have to in order to, well, sell their ideas to the market.

Rack ’em Stack ’em Robots

My all-time favorite purposeful over-the-top is the tendency to pretend that prior to the cloud, every project was started with “rack ’em, stack ’em.” This is demonstrably false, as by the time the cloud was taking off, VMware’s market penetration was significant. And yet, the number of blogs/amount of marketing material that starts out with the premise that every application required waiting for physical server delivery and configuration is insanely high.

No. Enterprises, in particular, had to wait for VM allocation and configuration.

Another that isn’t really mainstream—and I’ve mentioned in other locations—is the AWS TCO calculator. The simple calculator is not a bad tool, and I’ve used it numerous times in the past, but the TCO calculator makes some assumptions about deployment costs that are a little wild, such as that TCO includes the cost of VMware and its supporting hardware for an individual app. Of course, that’s not how enterprises do it. There is a VMware infrastructure and it is shared across apps. While it would increase the complexity a tiny bit, a simple checkbox that asks, “Do you already have a VMware cluster?” would go a long way—or better, one that asks how many apps you are running on VMware and divides the overhead by that number before including it in TCO. But of course, if you are getting your TCO comparisons from a competitor, expect the TCO will be stilted, no matter who is generating it.

Oversimplification

Whether it is infrastructure orchestration or app deployment, there is a lot of content out there that talks about how much easier infrastructure as code will be, and how much less documentation we will need. This, sadly, is a bogus premise. Whether you’re using the 50,000 service offerings of AWS or the power of HashiCorp’s Terraform—or any of half a dozen other competitors—it is complex. We’re not doing anyone any favors by glossing over the complexity that inevitably occurs in enterprise-class deployments, and we’re doing a massive disservice every time someone claims that documentation needs will be less because it’s “self-documenting code.” Self-documenting code sucks without a ton of comments in App Dev, and it’s worse in deployment. Employees new to the process need, and should be provided, solid documentation on how the system works and where different pieces fit.

We’re deploying complex apps on complex infrastructures with evermore complex compliance and security requirements. It is not simple.

All or Nothing

There is a belief among too many aficionados that their way is the “One True Way.” The fact of the matter is that all enterprise application portfolios are complex and there is a metric ton of extant code that must be managed. A startup with one web-based app (no matter how large it may be) or a games developer focused on Android as its only platform might well have agile and DevOps as their only development/deployment methodology. No one else does. The enterprise running a hundred or a thousand different apps on several platforms is not going to flick a switch and say, “We’re all X now,” no matter what X is. Anyone who has tried to standardize the database in an enterprise knows that just doesn’t happen (I did, as an architect in a financial services org. It was ugly).

Some projects are simply great fits for agile and DevOps—those with a high rate of change, where a little bit of instability in return for rapid feature rollout—while others simply are not—ones that maintain data that must be rock-solid, ones with a low level of change, etc. Any given enterprise is a mix of these things. Back in the days of the language wars, I used to say, “Right tool for the job,” and today, in the days of the architecture/automation wars, I say the same thing. If the project is rapidly evolving and you want lots of small changes in a constant stream, agile and DevOps are the right tools. If the project moves slowly and has an emphasis on stability or data quality, it’s not a great candidate for these tools at this time.

I’ve talked about some of the bad vendors in this post, so I’ll call out IBM for being a good vendor on this point. Looking at the company’s model for moving the mainframe is a good example of how you could look at all of your IT, because IBM doesn’t say, “This changes everything!” It says, “Here’s how to tell what offers the most bang for the buck in moving to agile and DevOps.”

Just Keep Rocking It

Working in IT? You’ve been keeping your org running. Don’t start second-guessing your gut now just because the new shiny is being waved in front of you. Learn, change, do. But don’t rush into something with misinformation. Obey your gut and keep rocking your org’s world.

— Don Macvittie

June 20, 2018
Picking a Git for the Enterprise
Some of my Agile and DevOps transformation work, not surprisingly, involves helping clients with tooling adoption—to set up, scale and operate across the organization. This blog piece is about a recent experience of setting up Git across a client organization.

Git, as most of you are aware, is a fundamental building block for many of the modern engineering practices associated with Agile and DevOps. Software configuration management tools such as Git, in simple words, allow you to track and manage your software code and configuration changes in the most-effective, efficient and distributed way. Git, as the choice of source control, has remained steadfast over the years, while other tools across various categories of DevOps tools have seen their fortunes go up and down with the ever-changing technology landscape of DevOps tools. In fact, one new buzzword is GitOps—some even calling it the next stage of evolution for DevOps.

Origins of Git

More than a decade ago , the Linux community faced a challenge because none of the existing revision control tools met their need for a distributed version control tool. And from that need Git was born. In the words of the creator of Git, Linus Torvalds, “The main issues with SCMs is the politics around who can make changes.” Ever since its creation, Git has radically changed the notion of software configuration management (SCM), by enabling engineers to work remotely and autonomously. (If you are new to Git and interested in exploring more about Git and its features, Atlassian has a tutorial and GitHub has a list of resources.)

Git and More

While Git as the core product is fundamentally the same whichever flavor your prefer—GitHub, GitLab or Bitbucket—the wrapper around it determines the important non-functional characteristics such as operatability, security, usability and maintainability. Our quest for an enterprise-scale Git focused on the wrapper and not the core product itself, as much has been written, debated and documented on the core product of Git itself already. The value and relevance to enterprises is in the wrapper that these productsplatforms provide.

We looked at the core product and related offerings; as you can imagine, the three tooling vendors have different positioning and taking different directions with the future road map for their respective tools. Bitbucket’s strength lies in the fact that Atlassian is bundling the product with the omnipresent Jira Software and Confluence. GitLab’s road map seems to be taking the product beyond Git and into the idea of a single product for your entire pipeline automation, from concept to cash. GitHub, which is being acquired by Microsoft, is increasingly relying on the strength of integrations with other tools and the workflow capability the company is bundling with it.

(I avoid an overemphasis on the commercial aspect in this blog; however, I’m not ignoring it completely. Part of the reason is due to the fact that enterprise pricing is not entirely transparent and may vary wildly depending on organization’s negotiating capability, the scale of usage, future potential and marketable track records as perceived by the tooling vendors. This blog is also not meant to be a feature by feature comparison, as this is something you can Google and find out yourself very easily.)

The Verdict

Image1; Github Enterprise – Pros and Cons

Image 2: Gitlab Ultimate – Pros and Cons

My Recommendation: It Depends
1. I liked the vision of GitLab as a single-stop tooling platform for continuous integration/continuous delivery (CI/CD), which goes beyond source control. I think the tool is simple and intuitive to use and great for small to midsized setups or even large enterprises that are focused on having smaller and autonomous teams.
2. GitHub seems to be well-suited for large and complex enterprises with significant outsourced and offshore-based technology teams.
I would love to hear your views on what has been your thinking with regards to choosing a Git-based product for your enterprise or teams. Meanwhile, here are some links you might find useful in your decision-making:
1. Why and how GitLab abandoned Microsoft Azure for Google Cloud – https://venturebeat.com/2018/04/06/why-and-how-gitlab-abandoned-microsoft-azure-for-google-cloud/
2. Tooling integrations of GitLab – https://docs.gitlab.com/ee/integration/README.html#doc-nav%20for%20list%20of%20integrations
3. GitHub add-ons are listed at Addons are listed at https://github.com/marketplace
4. Security and scalability info of GitHub is at https://github.com/jonico/github_security_and_scalability_overview
5. Products that integrate with GitHub platform – https://github.com/works-with
6. Pricing of GitLab – https://about.gitlab.com/pricing/
— Aditya Vadaganadam
June 18, 2018