devopsy.kinsta.cloud

Category: Blogs

Software Testing: The Comeback Kid of the 2020s

The past 15 years have been rough on software testers. The rise and fall of outsourcing, Agile growing from a manifesto to a movement and ever-shrinking release cycles have all taken a toll. By 2011, Albert Savoia walked on stage at the Google Test Automation Conference (GTAC) dressed as the Grim Reaper and declared testing dead. Since then, the emphasis on the “automation” part of “test automation” has fueled demand for Software Development Engineers in Test (SDETs) and left many testers wondering if they must learn programming to save their jobs.

If you look at how frequently people are searching for “software testing” on Google, the trends seem to suggest that the profession is, if not dead, at least flatlining.

However, I think the times are a-changin’. The pendulum will be swinging back—to the point where software testing could be the comeback kid of the 2020s. Sounds crazy, I know. But consider some developments that could turn things around.

Developers Don’t Want to Bear the Testing Burden

On Agile development teams, the party line is that unit testing is essential. It’s the most efficient way to expose implementation errors as they’re introduced. You can feasibly cover each function/method when you test at this level, plus when a test fails, you know exactly what function is broken. Moreover, having a suite of effective unit tests establishes a safety net that alerts the team whenever changes break previously-verified functionality. Those are just a few of the reasons why unit testing forms the foundation of the Agile test pyramid.

But, if you talk to developers in a casual setting, the truth starts to come out. Unit testing requires a lot of work, and they’re skeptical about whether it pays off. Just skim through a few of the 2.5 billion results returned by a Google search for “Is unit testing really worth it?” to get an idea of some of the issues.

Unfortunately, a seemingly endless amount of work is required to ensure that unit testing delivers long-term benefits as a regression testing safety net. Developers are committed to progression testing, not regression testing. Although developers on Agile teams usually write unit tests to check new functionality, few keep them up to date as the code base evolves. As the team moves on to another sprint, these tests become regression tests. Then, little by little, they start failing—but developers have moved on. The number of working unit tests at the base of the Agile test pyramid erodes, as does the level of confidence the test suite once provided.

In fact, data from our internal studies on financial instructions across EMEA shows that as an iteration ends, unit tests cover about 70% of the new code. After a few iterations of code getting extended, refactored and repaired, the original unit tests provide only about 50% coverage of that original functionality. This drops to 35% after several more iterations, and it typically degrades to 25% after six months.

Is Unit Testing Doomed?

Ultimately, developers don’t have the time or desire to keep these tests current over the long term. Unit testing has been a best practice for more than 20 years, yet despite waves of unit test automation tools (including one created by Albert Savoia not long before he declared testing dead), unit testing remains a thorn in developers’ sides. Does that mean we give up the benefits of unit testing altogether? Not necessarily.

In order to take on unit testing per se, testers would need to understand the developers’ code as well as write their own code. That’s not going to happen. But, you could have testers compensate for lost unit test coverage through resilient tests they can create and control. Professional testers recognize that designing and maintaining tests is their primary job and that they are ultimately evaluated by the success and effectiveness of the test suite. Let’s be honest, who’s more likely to keep tests current, the developers who are pressured to deliver more code faster, or the testers who are rewarded for finding major issues (or blamed for overlooking them)?

Another option is to consider new testing approaches that achieve unit testing benefits for today’s most popular development architectures—but without requiring knowledge of the code. Enter microservice contract testing.

Microservice Contract Testing: The New Unit Testing

Interest in microservices (the blue line on the graph below) has been rising rapidly since 2015. In fact, it seems to be on the exact opposite path from software testing (red line).

This rise is hardly surprising. From the architecture perspective, there are significant benefits to microservices. Initial forays into service-oriented architectures (SOA) were a huge step forward in enabling reuse and flexibility. Business logic formerly implemented in monolithic applications was freed and released as isolated independent services, which were loosely-coupled and highly-distributed.

Microservices take the decoupling and granularity to new levels. Business logic is now implemented in the smallest, most discrete units possible. Functionality that would have once been a single service is now distributed across tens, or potentially hundreds, of microservices, each of which can be independently developed and deployed.

In addition to enabling unprecedented agility and scalability, this extreme decoupling opens up promising new options for testing. With the initial waves of services and APIs, API tests had little choice but to pass through a fairly broad set of business logic, which was likely implemented through multiple units of code (e.g., functions).

If an API test failed, there was no clear pointer to what specific code function needed to be fixed. That required unit testing and/or additional debugging.

Now, with each microservice implementing an extremely focused unit of business logic, you know exactly what code is broken when an API test fails. Why spend the time and effort on unit testing if you’re already getting the benefits from something that’s considerably less painful?

You might be thinking, “Testing hundreds of independently-evolving microservices is just going to present a different pain.” Correct. Each integration point is a potential point of failure, and testing all the possible integrations is a logistical nightmare—so don’t. Instead of testing how each microservice interacts with all the other microservices it touches, perform contract testing instead.

Very basically, contract testing helps both microservice consumers and providers ensure that they’re meeting expectations in terms of message format and data. The microservice consumer adds a contract that specifies expected request and response pairs for its various interactions with other microservices. Each contract is used to create a virtual service that the consumer can then test against. If the consumer’s changes result in incorrect/unacceptable request messages, they’ll be alerted immediately by a contract failure message triggered from the virtual services.

On the flip side, the microservice provider can use the same consumer-specified contracts to ensure that their own changes don’t break the functionality which consumers depend on. If the actual provider response suddenly fails to meet consumer expectations, they, too, get a rather clear and telling contract failure message.

The beauty of this approach—even beyond the fact that neither consumer nor provider ever has to stand up the whole spider web of interconnected and independently-evolving microservices—is that you get very specific unit-level failure information without burdening developers. As soon as testing moves away from the code level to the API level, it doesn’t need developers doing it. You certainly don’t need developers to deal with the maintenance, and you really don’t even need them to set up the test. Instead, the task can be delegated to people who view testing—not development—as their profession. We call them testers.

Looking Beyond Unit Testing Is Essential for Ensuring a Positive User Experience

Nevertheless, hyperfocusing solely on unit testing of any flavor can leave you blind to many critical issues. For example: Does every step of the end-to-end transaction work as expected—from whatever mobile or browser interface the user happens to have, through the backend (which might interact with custom/legacy applications, packaged applications, mainframes, databases, third-party services, etc.) and back to the user? Will these same transactions perform acceptably under a sudden increase in demand? If the user exercises the application in ways that the developers didn’t anticipate, will the application respond in a reasonable manner, or at least fail gracefully?

The answers to such questions lie beyond the horizon of the testing performed by the typical Agile team, which rarely extends beyond unit testing and a little integration testing.

However, as organizations invest millions in digital transformation initiatives, this doesn’t cut it. Maximizing that investment requires a flawless user experience from start to finish, 24/7. Professional testers thrive on exposing the glitches that developers tend to overlook but that would cause a CIO to cringe.

I’m confident that software testing will surge in importance in the 2020s if we commit to expanding its scope and effectiveness, which will ultimately elevate its business value. As the pendulum swings back, testers can’t expect to just hang on for the ride. Willingness to jump on the momentum of this decade’s trends—for example, stepping in to solidify the foundation of the Agile test pyramid and embracing new practices such as microservice contract testing—will be essential for navigating the turnaround.

April 24, 2020
Multi-Cloud Cost Optimization For The Enterprise

Multi-cloud is an increasingly popular approach for deploying enterprise computing assets. But, in the same vein, managing cloud costs has become a huge challenge. Whilst public cloud continues to grow in popularity, there are many factors that can increase a cloud bill that needs to be taken into consideration. A smart cloud cost management strategy certainly helps to avoid any unwanted billing surprises. Enterprises progressing through their cloud adoption need one in place to control their spend.

The benefits of cloud infrastructure—scalability, control, security, etc.—are easily seen, but there are challenges, too. Perhaps the biggest challenge of cloud cost management is the difficulty that organizations have in tracking and forecasting usage— these uncertain budget costs can be a massive cloud management pain point. The ability to scale up and down on demand has allowed resource procurement to transition from sole ownership of the finance or procurement team to stakeholders across IT, DevOps and others. Procurement is now in the hands of a group of cost-conscious stakeholders who are responsible for understanding, managing and optimizing costs.

How much will the public cloud cost? You should begin your cloud cost management strategy by looking at the public cloud providers’ billing models—just like any other IT service, the public cloud can introduce unexpected charges. How much storage, CPU and memory do your applications require currently? Which cloud instances would meet those requirements?

Then, it’s a question of estimating how much those applications would cost in the cloud and comparing these figures to how much it currently costs you to run them on-premise. If you plan to use multiple public cloud providers, integration and other factors can lead to unexpected fees—try and plan application deployments to see where you might be liable for extra costs.

Initially, it seems that most vendors offer similar packages and prices—when you examine them in detail however, perhaps one vendor has a much lower price for certain types of workloads. Understand your business requirements before committing to a cloud vendor, and avoid vendor lock-in. Moving workloads from one cloud vendor to another can sometimes be difficult. If you don’t do your due diligence here, it can be subsequently too difficult to migrate applications or workloads after they are in production.

Confronting Cloud Costs

You must first identify waste by uncovering inefficient use of cloud resources. Cloud cost management is not a one-and-done process, but you can make a start saving money on your cloud infrastructure costs if you address key areas that account for the majority of wasted cloud spend and budget overruns.

Visibility

Ensure teams have the direct ability to see what they are spending. It’s easy to get carried away spinning up services, unless you know exactly what you are already spending. Identify what you have, and who owns it. Tag resources with user ownership, cost center information, product name and others to give you a better handle on where the spend originates. This information can be used to track usage through detailed billing reports.

Budgeting

Once you have a handle on what your spend is, set budgets per account. Doing this after establishing a baseline ensures that you are setting practical and realistic budgets that are based on the actual usage. Look to whitelist instance types (RDS & EC2) to only allow instances of specific types, classes or sizes.

Manage Storage Lifecycle

Ensure that you are rotating logs and snapshots regularly and backup and remove any storage volumes that are no longer in use. Ensure that you are using only one logging configuration and have added additional ones only when absolutely necessary. Also, ensure that sandbox or trial accounts are only utilized for exploration purposes and for the duration committed.

Use Containers

Another technological solution that can help to reduce operating expenses is the use of containers. Often used by IT teams taking DevOps approaches, containers package applications together with all their dependencies, making them easier to deploy, manage and/or migrate from one environment to another. Containers can also be more cost-effective on one hand but can cause more complexity, and therefore increase costs, if built in the wrong way.

Review Regions

Prevent staff from provisioning unapproved virtual instances from the marketplace that include software license costs, or from using specific OS or DB engines from vendors with whom you do not have enterprise agreements in place or are too costly to run at scale. Review in which regions you have services running. The cost of services per region can vary as much as 60%. You need to ensure you are balancing the need with running services in a given region with the cost of doing so. You can use instance scheduling to start and stop instances on a planned schedule. Shutting down environments on nights and weekends can help save you 70% of runtime costs. Look to determine which environments need 24/7 availability, and schedule the rest.

Use a Cloud Cost Management Vendor

Many organizations decide that tackling these cost optimization chores on their own takes too much time and skill. Instead, they leverage services from reputable cloud cost management vendors. Cloud cost management is one of the major pain points organizations confront when migrating to the cloud—cloud costs are difficult to estimate without some kind of assistance, due to the complexity of cloud infrastructure.

April 23, 2020
Pulumi Tightens DevOps Platform Integration

Pulumi today released the 2.0 release of its open source platform for automating the provisioning of IT infrastructure in the cloud, providing tighter integration with a dozen different continuous integration/continuous delivery (CI/CD) platforms and source code management (SCM) systems. Via the latest update Pulumi also now includes CI/CD Apps, through which pull requests will trigger Pulumi previews and updates.

In addition, Pulumi has added tools to preview changes, while making it easier to share architectural patterns, libraries and best practices.

Finally, Pulumi 2.0 adds additional tools to enforce policies, simplify testing and manage secrets.

Pulumi is designed to enable developers to provision cloud infrastructure using familiar programming tools such as Python, JavaScript, TypeScript, Go and .NET/C#. That approach eliminates the need to master YAML files or other proprietary languages and templates.

Pulumi CEO Joe Duffy said the goal is to accelerate the rate at which management of IT is shifting left toward developers by providing them with the “superpowers” need to manage cloud infrastructure. Thus far, Pulumi claims to have more than 10,000 users of its tools.

In the wake of the economic downturn brought on by the COVID-19 pandemic, it is expected the rate at which control over IT has been shifting left will accelerate. As part of an effort to either contain or eliminate headcount, many organizations will reduce their reliance on IT operations staff by giving developers more direct control over IT infrastructure.

At the same time, however, Duffy noted that many IT operations personnel are finding it relatively simple to master Python, which they can then use to leverage Pulumi to automate the provisioning of large amounts of cloud infrastructure to become more efficient. Some organizations may prefer to retain IT operations staff that have learned how to program.

It remains to be seen to what degree tighter integration with CI/CD platforms might encourage developers to take more control over IT infrastructure. Support for the CI/CD platforms supported by Pulumi—Jenkins, Spinnaker and GitHub—will make it easier for developers to achieve that goal. Less clear is the degree to which developers want to take control over infrastructure. Regardless, many of them may soon have little choice in the matter.

Of course, Pulumi is not the only framework via which the provisioning of cloud infrastructure can be automated. It does, however, make it easier for developers to provision infrastructure without having to spend time learning the nuances of another set of programming tools. Even in organizations that do shrink the size of their IT staffs, there will still be pressure on developers to deliver more code faster. The amount of time developers may want to allocate to managing IT infrastructure is likely to be limited at best.

Whatever the path forward, many organizations will soon discover they can’t afford to wait any longer for their internal IT cultures to embrace best automation and DevOps practices. Economic pressure to optimize constrained IT resources are likely to become intense. No one may know for certain how long the downturn may last, but it is already apparent many organizations will be trying to do a lot more with less in the days ahead.

April 21, 2020
Metropolis Now: The Two Worlds of Employment in the Age of Automation

Current events have revealed that there are two worlds in the employment landscape. One is digital, the other analog. For the most part, those in IT—the digital workers—have been unaffected by the spike in unemployment due to the economic side-effects of the COVID-19 pandemic. But, it doesn’t mean they’ll be untouched in the long-term. As current events demonstrate, when it comes to the essentials in life, we’re all connected. Yet, the divide will continue to separate us to the detriment of all unless we do something about it.

When observing current events, I can’t help but think about Fritz Lang’s 1927 silent movie, Metropolis. It’s a science fiction film that depicts a world in which a small number of people live a privileged life in skyscrapers that tower high above the city. The rest of the population toils away below ground, doing the mundane work required to keep the city running. It’s a stunning piece of cinematography. The sets and special effects are breathtaking. What’s also impressive is that, for better or worse, so much of what Lang presented nearly 100 years ago has come to be.

You can view the full-length version of Metropolis here.

Figure 1: Scenes from the 1927 silent movie, Metropolis by Fritz Lang.

Lang’s vision of the future has a strange, almost eerie prescience for me, particularly as someone who has spent most of his adult life working in IT. It’s one that’s entirely possible, yet one I hope we avoid.

Allow me to elaborate.

Life Is A-OK in the Cloud

There’s a good argument to be made that today we live in Lang’s Metropolis, a world in which those who are doing really well live in the light of society while those who are just getting by live below ground in darkness.

The widening gap between prosperity and economic hardship is a trend that’s been unfolding over the last 30 years. We’ve become accustomed to it. Sadly, it’s no longer newsworthy.

What is newsworthy is the dramatic spike in unemployment due to the business shutdowns caused by the COVID-19 pandemic. The uptick in unemployment reveals a troubling set of circumstances: If you’re a digital worker chances are you’re still working. If you work in the analog world, that place where factories, restaurants, airlines, movie theaters, hotels, cruise ships and warehouses exist, there’s a good chance you or someone you know is out of a job, for now anyway.

Take a look at the graph from the US Private Sector Job Quality Index, a project from Cornell University Law School and others, by way of vox.com. It lists the jobs that are most vulnerable to layoffs due to the COVID-19 pandemic. IT workers don’t even make the list. It’s as if we live in another world.

Figure 2: Information workers are absent from the list of jobs at risk due to COVID-19.

The long and the short of it is that for developers, sysadmins, SREs and all the other people working in information technology, the recent economic downturn is but a blip in the daily news feed. For those manning a cash register, taking a ticket at the local cineplex, cutting hair or driving for a rideshare service, it’s a life-altering event. Or, to put it terms of Lang’s film, those of us who live in the clouds are doing well, and for those on the ground, it’s a different story.

Now, consider this: What if all the people who are presently laid off from their jobs find out there are no jobs to go back to? What if the economic recovery is slower than anticipated or society gets so accustomed to doing without that consumption doesn’t resume? Is such a scenario possible? Yes. Is it probable? Dunno. Will those of us in IT who work remotely all over the planet, from the comfort of our wired office, suffer? I doubt it. But, as for the rest, what then?

Let’s go back to the movie.

A Workforce Divided

There’s a point in the film when the protagonist, Freder (the son of the industrialist who built Metropolis), goes to his father to inquire about a catastrophic underground explosion shown earlier in the film.

The son asked, “Your magnificent city, Father, and you, the brain of this city, and all of us in this city’s light … and where are the people, Father, whose hands built your city?”

The father responded, “Where they belong.”

The son asked, “Where they belong? In the depths?”

His father nodded his head yes. (See the scene here).

There you have it. With that one physical gesture, Lang foreshadows a future which might very well be at our doorstep. As I mentioned earlier, it’s eerie, it’s prescient and it looks as if it’s coming to be.

What Does This All Have to Do with DevOps?

Those of us in DevOps have made valuable contributions to the world. We’ve done dramatically more good than harm. We’ve also been well compensated. The average salary for a SRE in the USA is $131,340, with a low of $60K and a high of $192K. Yet, the top salary for grocery clerk at Ralph’s supermarket is $22 an hour, which comes out to $44K a year over a 50 week year.

Do SREs deserve such a high salary? Of course, they do. Does a grocery clerk deserve only $44K a year in comparison? At the end of 2019, it would have been easy to say, yes. It’s a low skill, low education job. But that was then, and this is now. As of this writing, toilet paper is a premium commodity and the shelves need to be stocked with it. I’ll wager that in some circles, paying someone $50 an hour to get the rolls on the shelf is reasonable compensation. It all depends on how much people want toilet paper.

Am I being a bit dramatic? A little, but still, it’s worth thinking about.

So, what’s the important take away? Let’s go back to Metropolis one last time.

At the beginning of the film, there’s a scene in which the protagonist, Freder, was frolicking about in a lush arboretum-like greenhouse atop a skyscraper. He was surrounded by pretty maidens dancing. An elevator door opened into the garden. Freder observed as a group of raggedy waifs from beneath the city exited out of the elevator. A woman leading the waifs was at the head of the group. The waifs looked around in amazement at such luxury. Then, Freder’s servants ushered the group back into the elevator to exit. Freder was obviously affected by the waifs. He went into the depths of the city to investigate.

Shortly thereafter, Freder went to see his father to inquire about the explosion I described earlier. His father asked, “What were you doing in the machine halls, Freder?”

The son responded, “I wanted to look into the faces of the people whose little children are my brother, my sisters…”

It’s a powerful scene. It makes me wonder how many of the faces I’ve seen of those who were working in February are now sitting home, unemployed and unable to pay the rent in April.

The takeaway is this: We’re all connected at a level much deeper than the trivial interactions of the given social network. Current events have demonstrated the fact in spades. COVID-19 was first reported in China around November 17, 2019. On April 4, 2020, less than six months later, there were 240 cases reported in the state of South Dakota in the United States. If that’s not connection, I don’t know what is.

Those of us who work in the cloud are doing quite well, despite the setbacks caused by the global pandemic. But, there’s a growing number of us who are not doing so well and won’t be for the foreseeable future. It’s easy when everything is peaches and cream to be unaware of a world in which six-figure salaries are not the norm. But, when things go south and there’s no toilet paper to be had, the realization that we’re all in this together smacks us square in the face, like it or not.

The question then becomes, given that we’re all connected, what type of world do we want to share, the one in Lang’s Metropolis or something better?

It’s something worth thinking about. The pandemic will pass, but the underlying disparities will remain unless we do something about them.

Don’t forget to check out my new, free book, “The Impact of Automation.”

This book takes a serious examination of the history, impact and results from automation on our society and culture. Hope you enjoy it.

April 21, 2020
Open Source Vulnerabilities Were Up 50% in 2019 — How Will It Impact Software Development in 2020?

Open source vulnerabilities have been on the rise in recent years, but 2019 was truly one for the record books with a spike of nearly 50% over the previous year.

According to the recently released State of Open Source Security Vulnerabilities report by the WhiteSource research team, the number of vulnerabilities jumped from 4,100 in 2018 to 6,100 in 2019.

Figure 1: Number of reported open source vulnerabilities per year.

In hopes of better understanding what is behind this rise in the number of open source vulnerabilities, what it tells us about the state of open source usage in modern software development, and even where we are likely headed in the years ahead, let’s take a look at the report’s findings for insights on the current state of open source security.

More Code, More Vulnerabilities

According to the research report, the primary driver behind the rise in open source vulnerabilities is a function of the growth of open source. There are now more open source projects, code and members of the community than ever before.

All of these good folks are working hard to not only write more code, often with the backing of large tech giants, but also to seek out vulnerabilities in the code that can put the users of their components at risk. The combination of more code being written and the number of eyeballs reviewing the code for those inevitable human mistakes, comes together to produce a larger number of vulnerabilities being reported.

The increase in the number of vulnerabilities in open source components will have a considerable impact on software development. In recent years, we have seen open source components playing a bigger role in how developers build their applications. Most estimates believe that open source components comprise between 60-80% of the codebase in most modern applications. When a vulnerability is reported in a popular project such as Apache Struts or the Linux kernel, then huge swaths of developers can quickly find their software in need of patching.

The Good, the Bad and the Bazaar

WhiteSource’s research revealed the reassuring news that over 85% of reported open source security vulnerabilities have a fix available.

One of the reasons for this improvement is the fact that more enterprises are dependent on open source components for their own software, so they are investing in making it more secure, via bug bounty programs, backing foundations that support open source security or backing the projects themselves.

However, even as the situation in the field appears to be improving, there is still a way to go.

The fact that many published open source vulnerabilities are not indexed in one central location adds complexity to this challenge for development teams attempting to stay on top of published open source security vulnerabilities. If proprietary software is still considered to be the classical Cathedral, well-organized information and support under one roof, then open source is very much the Bazaar.

The WhiteSource report found that only 84% of known open source vulnerabilities appear in the National Vulnerability Database (NVD). This means that information about another 16% of the known vulnerabilities is out there, spread out among a wide range of resources. These might be security advisories, bug trackers and a laundry list of other locations. While 45% of reported open source vulnerabilities that were not initially published on the NVD eventually end up there, that could take months since their publication on other resources.

The challenge for organizations is that they run the risk of using a vulnerable component unaware of the security updates, while hackers are scouring all resources, looking for vulnerabilities that could be their next meal ticket.

Given the evolving security challenges facing organizations, what does the future hold for open source security in the year ahead?

Our Predictions for 2020

The easiest prediction that we can provide is that 2020 will have even more reported open source vulnerabilities than were published in 2019. The only question is: How big it will be? Chances are that the count will be more significant due to recent advances making it easier than ever to report and an open source vulnerability.

This past year saw the launch of GitHub Security Lab which aims to help researchers, maintainers and users easily report an open source vulnerability and publish a verified fix in one centralized location. By simplifying the reporting and documentation process, GitHub has gone a long way in helping their users to protect their software with better quality reporting.

Key Takeaways

For many, the rise in the number of reported open source vulnerabilities might be concerning, making us confront the fact that we probably have plenty of them in our software right now. However, the situation is actually improving, and even heading in the right direction. When vulnerable open source components are reported, we get to track them and move quickly to remediate. Only once you know you have a problem can you begin to fix it.

Hopefully, the increase in security awareness will keep pushing for a stronger, more organized and better supported open source community that will be resilient in the face of even more vulnerabilities that are likely to show up in next year’s research report.

April 20, 2020
Embracing the Journey to Public Cloud

One of the fascinating competitions in today’s business world is the one between the digital disruptors—companies whose business vision is rooted in technology and driven by the cloud—and the so-called incumbents.

One sector where this competition is particularly intense is financial services. In this sector, the digital-first companies typically don’t compete with banks and other financial institutions directly. Instead, they target specific functions based on a clear—and often data-driven—understanding of what customers want. This strategy has proven particularly successful with millennials. For example, until recently the norm for giving money to a friend or family member was to write a check. Now, almost two-thirds of 20- and 30-year-olds use payment apps, such as Venmo.

In healthcare, a different pattern is emerging, one where digital-first giants either buy or innovate their way into the sector. Examples include Amazon’s billion-dollar acquisition of the online pharmacy PillPack and the new Apple Watch, which is capable of taking electrocardiograms.

Whatever the sector, digital disruptors have one characteristic in common. They leverage the capabilities of the cloud to the maximum extent possible. A shift in power toward digital-first companies is underway, and the cloud plays a major role in helping these companies establish themselves.

Many incumbents are just now taking their first steps on the journey to the cloud, and still working on the challenges involved in migrating their existing legacy applications to more scalable and agile public cloud environments. While they’re engaged in this process, digital insurgents are already exploiting the full potential of the cloud to deliver solutions that meet emerging customer needs associated with today’s evolving lifestyles.

In highly regulated industries, such as financial services and healthcare, major brands will not necessarily see an immediate decline in their customer base, nor profits. Nonetheless, digital-first companies are capturing millions of customers annually, and this growth poses a considerable challenge over time. Embracing the journey to public cloud is crucial for legacy enterprises.

The most successful cloud-based disruptors use experimental sandboxes as a critical component of development. The public cloud can drive progress toward almost any business goal involving IT—operational transformation, new market penetration, new product launches, automation.

Digital transformation to the public cloud is also the only way companies can leverage storage scalability and the essential innovations of the open-source community. There are still lingering concerns among executives in highly regulated, data-sensitive industries concerning privacy and regulatory compliance, and these can lead to hesitation. The face is, public clouds have been in place for over two decades now, and their security is often superior to older on-premise security. Incumbents can, therefore, tap into the public cloud to ensure safety for mission critical workloads.

To accelerate the transition to the public cloud, consider the following best practices.

Learning to Fail Fast and Learn from Experience More Quickly

The Silicon Valley maxim to fail fast may run counter to incumbent corporate culture, but it is the best path to success in the new digital reality. The key is being able to learn from failures quickly and adjust accordingly.

Partnering for Progress

A digital native approach to business is often lacking in the corporate culture of incumbents. Cloud partners that have a digital disruption in their DNA can play an important role in driving cultural renewal at every level of the organization. A reliable cloud service partnership can accelerate concepts, pilots, staffing and other mechanisms designed to deliver value quickly and securely.

Re-Examining Compliance Processes

Operations should be streamlined to transform enterprise IT to be well-suited for the cloud. Companies can apply artificial intelligence to supplement human intervention, and encourage cloud adoption among employees. First, building a solid foundation, then working your way up, enables businesses to make important changes that transform the enterprise into an environment that is compliant by design.

Successfully competing with digital natives means using the cloud to find new opportunities to streamline and better comprehend customer needs and behaviors. It also means being unafraid to change time-honored business practices. At the same time, in highly regulated and data-sensitive industries, compliance and security must be prioritized. Cloud transformation has quickly become vital for companies in all sectors and represents an essential foundation for future business success.

April 17, 2020
ClickShare Vulnerabilities May Have Been Patched, But They Mask a Much Bigger Problem

I think we can all recall a time in recent memory where, in a meeting or at a conference, someone has had issues with presentation technology. It happens so often that there is almost an expectation of a clunky experience, at least initially. It stands as no surprise, then, that ClickShare’s seamless app was immediately popular with end-users. For them, there is nothing easier than using a ClickShare application to push a presentation from their laptop, tablet or smartphone over to a big screen or conference room projector.

Belgian-based digital projection and imaging technology supplier Barco designed their automation platform to work that way, and big business embraced the concept. FutureSource Consulting puts Barco’s market share in conference technology at 29%, with integration into 40% of all Fortune 1,000 companies.

When researchers from F-Secure revealed in December that the seemingly innocuous automation platform was riddled with security vulnerabilities, it sent shockwaves through the business community. The uncovered security flaws are critical in nature, and could potentially enable any number of malicious activities.

Researchers demonstrated how the vulnerabilities could allow remote users to snoop active presentations, create backdoors into secure networks or even configure a spyware distribution server that would infect every user connecting to a Barco device. Suddenly, companies were faced with the prospect of having serious security problems installed directly inside conference rooms and offices throughout their organization. And because of the nature of the vulnerabilities, a single compromised device could support a network-wide breach.

“An attacker who successfully compromised one unit gains the ability to decrypt as well as produce valid encrypted images for any unit, whether within one family or across families,” wrote F-Secure officials in their report. “Further, such an attacker may gain access to sensitive data at rest such as the configured WiFi PSK and certificates.”

To its credit, Barco has been extremely proactive in issuing patches and fixes to the vulnerabilities found within its products. Security vendor Tenable recently released a report showing 15 vulnerabilities across eight presentation tools, including Barco. As of February, only Barco has been active in deploying fixes.

Although some of the Barco vulnerabilities require hardware changes (and these will be a nightmare to deploy, if a firm acts to this degree to secure them at all), many of them can be corrected with software patches. This gives most enterprise users a seemingly good plan to fix their immediate problems, but they are hardly in the clear now. The problems with Barco are just the tip of the iceberg when it comes to dealing with vulnerabilities in well-known hardware and software products.

The Root of the Problem

Now that the immediate issues have been resolved, we need to ask how devices with serious security flaws ended up sitting in thousands of conference rooms worldwide, or why they were so poorly designed and programmed in the first place. It’s not like the F-Secure team was uncovering zero-day or previously unknown vulnerabilities. Ten of the flaws discovered in the Barco products were associated with well-known, common vulnerabilities such as code injection attacks. Most already had Common Vulnerabilities and Exposures (CVE) identifications.

So how did decades-old CVEs get coded, or even hardwired, into modern presentation tools? The only possible answer is that developers either didn’t know about them, or that security was not made a priority as the Barco devices were being designed. Sadly, this is a common situation, and certainly not exclusive to the Barco teams.

The best time to fix a vulnerability is while an application is being developed, long before it gets sent out to users. The worst (and most expensive) time is after a product has been deployed, or after it’s been exploited by hackers. This can be a hard lesson, and one that Barco will surely learn as its once-impenetrable market share takes a hit following this security fiasco.

Shifting security fixes back toward the development process isn’t easy, but is necessary in today’s world where even seemingly simple devices like presentation tools are both surprisingly complex, and also networked into everything else. In this environment, security must become an organizational best practice. It doesn’t matter if a company is programming apps for social media or manufacturing smart toasters, security must be considered in every facet of an organization.

Prioritizing security best practice and making it a shared responsibility is the goal of the DevSecOps movement, where development, security and operations teams work together to code and deploy secure software and products. It requires as much of a change in culture as anything else. The new mindset needs to be that deploying a working product with security vulnerabilities is just as much a failure as creating one that can’t perform its primary function.

In a healthy DevSecOps environment, anyone touching software should be security-aware, with developers receiving relevant and frequent training to avoid introducing disastrous bugs into their work. If the teams working for Barco had looked at security as a shared responsibility, there is no way that such a large collection of vulnerabilities, including decades-old CVEs, would have made it into their presentation tools.

The Safe Path Forward

Nobody wants to be the next Barco, having to explain why well-known security flaws were deployed through their devices to thousands of enterprise networks around the world. To avoid that fate, companies developing software or smart hardware should immediately prioritize security as both a shared responsibility and an organizational best practice. Creating a healthy DevSecOps program will take time and likely also require a shift in culture, but the results will be more than worth the effort. Robust DevSecOps can crush vulnerabilities long before they cause trouble.

For companies buying products and software, it’s in their best interest to support firms that have embraced DevSecOps. Doing so will go a long way to making sure that the devices and software obtained from them aren’t ticking time bombs waiting to be exploited by increasingly skilled attackers.

April 17, 2020
Digital.ai: The Companies Formerly Known As XebiaLabs and CollabNet Plus

Another shoe has dropped in the continuing story of TPG Capital‘s foray into DevOps. The company formed by the merger of XebiaLabs and CollabNet VersionOne is now Digital.ai. Additionally, the company has acquired Arxan, a leader in application protection.

I had a chance to catch up with Digital.ai’s CEO Ashok Reddy and Arxan COO Mark Lorion, who will be Digital.ai’s COO of Platform going forward. The video of our discussion which is also available on TechStrong.TV, appears below.

What They Said

Reddy made it very clear that Digital.ai is not content with simply adding this AppSec company to the mix. It is actively involved in due diligence operations on several other acquisitions. Reddy and the TPG team feel that the current COVID-19 situation affords those with cash to pick up some bargains. That may have been the case with Arxan, which was owned by private equity firm TA Associates, which acquired Arxan in 2013 for $132 million. TA may have decided it was time to get off the merry-go-round, given the unsettled state of things right now.

In any event, TA’s loss is Digital.ai’s gain. Arxan adds some much-needed security muscle and a blue-chip bank customer list. But, of course, the real play here is building out the end-to-end DevOps company that will compete with GitLab, GitHub, CloudBees, JFrog and others. We detailed this market in an article when the original merger was announced.

My take is that indeed Digital.ai is not a complete company just yet. It may not even be done in the DevSecOps space, as Arxan is not your typical DevSecOps technology. It may have been more of an opportunistic acquisition.

Also, in terms of executive team, Reddy has been quietly assembling a team made up of some of the best people he worked with at previous stints at IBM, CA/Broadcom and the executives from the acquired companies.

Stay tuned for more on Digital.ai’s continued evolution in the months to come.

— Alan Shimel

April 15, 2020
CD Foundation Serves Up Tekton Pipelines Beta

The team overseeing the development of the open source Tekton Pipelines under the auspices of the Continuous Delivery (CD) Foundation announced today the project is now in beta.

Christie Wilson, Tekton Project Lead and a software engineer at Google, said Tekton Pipelines are not necessarily a tool most DevOps teams will interact with directly. Rather they provide a foundation on which DevOps platforms can be built that will make it easier for DevOps teams to construct workflows spanning multiple continuous integration/continuous delivery (CI/CD) platforms.

As such, Tekton Pipelines should play a critical role in not just fostering interoperability but also alleviating concerns about become locked into a specific CI/CD platform.

The beta release of Tekton Pipelines is significant because it signals that the project is now stable enough to be incorporated in DevOps platforms and from here on will follow the same deprecation policies as Kubernetes in terms of supporting previous releases. However, Wilson noted that Tekton Triggers, Tekton Dashboard, Tekton Pipelines CLI and other components are still alpha and as such may evolve from release to release in a way that is not necessarily backward-compatible just yet.

In the meantime, the Tekton Pipeline team is encouraging all Tekton projects and users to migrate their integrations to the latest version of Custom Resource Definition (CRD), which is the application programming interface (API) supplied. The Tekton Pipeline team is also making available a migration guide.

The Tekton Pipelines project is one of several initiatives being advanced under the guidance of the CD Foundation, which is an arm of The Linux Foundation. Other projects include Jenkins and Jenkins X, a pair of open source CI/CD projects developed originally by CloudBees and Spinnaker, a CD platform originally created by Netflix. Tekton Pipelines are a framework that runs natively on Kubernetes that traces its lineage back to Google.

Premier members for the CD Foundation include CloudBees, Google, Circle CI, JFrog, IBM, CapitalOne, Salesforce and Netflix. Other members of the CD Foundation include GitLab, Red Hat, Harness and Rancher Labs.

Wilson said Jenkins X already supports Tekton Pipelines, while work involving Spinnaker is ongoing. It’s not expected that Jenkins, currently the most widely used CI/CD platform, will be able to employ Tekton Pipelines, said Wilson.

It’s not clear when Tekton Pipelines might be pervasively employed across multiple CI/CD platforms. In theory, as more applications are built on top of Kubernetes, the use of CI/CD platforms that run natively on Kubernetes should increase. However, most organizations that have already adopted a CI/CD platform such as Jenkins are continuing to use the same platform to build and deploy both monolithic and microservices-based applications. At some point, however, it’s expected those organizations will eventually migrate to a CI/CD platform that runs natively on Kubernetes. In many cases, different teams within the same organization may opt to standardize on different CI/CD platforms while still be able to share workflows, said Wilson.

Naturally, providers of DevOps platforms are already jockeying for position now that the race to support Tekton Pipelines as specified by the CD Foundation has formally started.

— Mike Vizard

April 9, 2020
Seven Effective Tips to Get the Most Out of your DevOps
It seems that every firm is trying to include DevOps in their software delivery cycle these days. This is understandable. According to the 2019 Accelerate State of DevOps Report, companies using DevOps are more likely to achieve elite performance in software development and delivery.

Companies such as Google and Amazon can be deploying thousands of updates a day. These rapid updates improve company performance and result in the provision of better software solutions for the end-user.

In this article, we will look at seven effective tips to get the most out of your DevOps so you can maximize success. Before we look at some of these tips, let’s briefly define DevOps.

What is DevOps?

DevOps is a term for a group of management practices that aim to quicken the deployment of changes to a system while ensuring high quality delivery. It incorporates management theories such as agile infrastructure and agile development. One of the most influential books on the topic, which resonated with a lot of influential business leaders in Silicon Valley, is “The Lean Startup” by Eric Ries.

At its heart, DevOps boils down to the idea that you should be able to implement changes quickly, so you can release a superior product to your customers faster. This ability to bring a superior product to market fast, gives companies that can achieve this edge an advantage over their competitors.

Review Your Organizational Structure

Collaboration is the bond that allows software companies to deploy and execute changes fast. Companies that are experts at DevOps classically reduce the obstacles to collaboration.

In traditional IT organizations, departments are siloed. They interact with each other only when necessary. Hence, they have limited knowledge of each other’s work. This model presents a linear process of developing, testing and deployment.

To reduce these silos, you need to first analyze your organizational structure, and identify obstacles to collaboration. This starts by ensuring management is on board with your vision. You need to:
- Review the job description of managers and create KPI that support collaboration.
- Create remuneration packages that foster closer collaboration between departments.
Addressing structural issues that impede collaboration between departments will help. You also need to put in place a system of communication between departments.

Fortunately, there are useful tools to smoothen continuous collaboration between different lines of business. Channels of communications should not be limited to sending emails or conference calls. Remember, DevOps requires continuous and fast collaborations to ensure fast deployment.

Using unified communications (UC) is an effective way to foster collaboration in a company. Unified communications integrates phone calls, email, chat, document sharing, conferencing and other platforms necessary to exchange information within the organization. Importantly, you can also access much of this information in one place.

Reduce Operational Hurdles for Deployment

The way an update is deployed will differ by company. There is usually a system in place to discuss targets and a series of checks in place before deployment. For example, department heads will come up with an idea. They will be developed, then reviewed by quality assurance before operations deploy it.

This can be a cumbersome and time-consuming process, which slows down the speed of development. The problem for many companies is that changes, both large and small, need to go through the same process of quality assurance before deployment.

Source: Tech Beacon.

While it makes sense to have this process in place for major updates, it should be possible to push smaller updates faster. Two things need to happen to achieve this:
- Empower staff to make decisions independently while giving them the opportunity to learn from mistakes without risk.
- Reduce the administrative hurdles to deployment by creating a ranking system for reviewing updates. This will allow developers to push small updates independently, or with minimal oversight.
Empowering staff to push changes enables you to speed up DevOps.

Plan in Small Batches

Planning in small batches is important in promoting DevOps in an organization. With small batch testing, the cycles of testing hypotheses, acquiring feedback and going at it again can be done within a very minimal time frame. It is fast and efficient—simple.

This feedback might feel obvious. Perhaps the better question to consider when planning in small batches is: How small is small? Let the INVEST concept in agile development help you out.
- Independent: Planned small batches should be independent of other parts.
- Negotiable: Every batch should be iterable and negotiable upon receipt of feedback from deployment.
- Valuable: Each one should add value to the project and the end-users.
- Estimable: Batches should contain estimable information for scope determination.
- Small: Small should be small enough to be processed within a few hours up to a few days.
- Testable: A planned batch should be testable and can be monitored continuously.
Results of deployment, testing and monitoring of each batch should then be deployed at least once a day. Also, in planning small batches, different departments should be kept in the loop. This will greatly benefit DevOps efforts in the organization.

Create Space for Collaboration

Even without DevOps, fostering collaboration between departments is imperative. You can formalize collaboration through regular meetings. However, departments are usually situated in separate office areas, floors or even different buildings. Think about having to walk to a conference room on a different side of the facility just for a meeting.

This kind of setup is an example of a bottleneck for collaboration in an enterprise. And with collaboration being the heart of DevOps, creating a company culture and office space conducive to teamwork is of utmost importance.

SpaceX is an example of a company that promotes collaboration throughout the organization through company culture and physical space management. Offices are open, and each person can see what everyone else is working on. This promotes motivation for employees to work passionately. Also, everyone has access to camera feeds from different parts of the factory, which inspires curiosity about what others are doing. Because of this culture, employees become dedicated and excited to accomplish results.

Take Advantage of Microservices

In processing complex IT systems, it is more beneficial to break bulks to smaller, more digestible pieces. This is where microservices come in.

Microservices or microservice architecture is an architectural style wherein a complex system is broken down into smaller services. Rather than treating a system as a whole, it is perceived as a collection of manageable pieces.

Teams simultaneously working on parts of a system as a whole makes it more prone to breakdown. Utilizing microservices makes monitoring, maintenance and testing easier. They are also loosely connected to each other which means fixing wouldn’t much affect the other parts. Moreover, each microservice is releasable independently.

As an example, Wix started out with a monolith which was useful at first when they were only handling 1 million sites. However, interdependencies and poor quality coding resulted in downtime which is ultimately bad for business. Now that they shifted to using microservices architecture, they quickly scaled up reaching 70 million sites.

Maintain Continuous Monitoring

DevOps promotes fast and continuous integration and deployment. A fast-paced environment is more susceptible to problems. Something at any point can fail within the software development life cycle. Continuous monitoring helps you identify mistakes fast. It ensures the optimal performance, reliability and health of the software.

Setting monitoring targets, like development milestones, can improve this process. A development milestone is an overarching category that can give an insight into your team’s actual performance. Monitoring tells you the performance of your DevOps implementation.

A method to consider is synthetic monitoring wherein your application undergoes simulated customer interaction. This way, you can monitor the exact action and performance of your software before they get released to actual users.

Practice Change Management

DevOps employs continuous integration, continuous deployment and continuous monitoring. It is a cycle of fast-paced changes. Change management is essential to keep the system run like clockwork.

It might be easier said than done because changes have effects on various stakeholders. This includes your customers as the end-users, security, regulatory compliance and company policies. With this, changes within the development, testing, deployment and monitoring should be cohesively managed.

Change management is intrinsically reactive. It usually happens because of feedback received after deployment. But with DevOps, change management should be proactive. Instead of managing large-scale changes, processes are broken down into smaller parts with clearly defined scopes. Furthermore, anticipated changes are scheduled, scaled and communicated across the board. Possible risks and problems are efficiently managed because of this.

Summary

No system is perfect nor exactly the same. The key to a successful DevOps implementation is assessing what works best for your organization. DevOps is not a standardized process. It is not a system that will work for every company. Rather, DevOps is a theory of management.

Improving DevOps at your firm will involve a system of continuous review and improvement. You need to understand what is working, the problems and what you can improve. This can all be done through continuous processes with the help of automation and collaboration. No matter the size of your software development projects, these simple tips and tricks will help you make the most out of your DevOps.

— Sam O’Brien
April 9, 2020