devopsy.kinsta.cloud

Tag: devops

Break-Even Analysis: Understanding the Impact of Automation
Determining whether automation is helpful beyond the CI/CD pipeline can be easier through a break-even analysis

The pursuit of automating away all the operational tasks in your organization doesn’t stop after you finish building a solid CI/CD pipeline infrastructure using the myriad tools available and making it stable.

There are many more one-off tasks not part of the CI/CD pipeline, but which are very important for managing the infrastructure and operating the applications running in production, that are not yet automated. These tasks could be very specific to your organization, but some common categories of these tasks are:
- Provisioning and maintenance of infrastructure, including patching, updating certificates and licenses.
- Maintenance of monitoring systems.
- Generation of reports and dashboards.
To Automate or Not to Automate?

A CI/CD pipeline is an end-to-end automated system that handles all aspects, from builds triggered by code change through deploying the built artifacts into production, with very little or no human intervention in between. The non-CI/CD tasks described above could be automated or be carried out manually.

An inexperienced DevOps team can easily get carried away by the notion of automating everything and end up spending time on low-priority tasks—sometimes, simply because using a new tool or the coding work involved in automating a task can be very attractive to the team members. While such endeavors would look great in a sprint demo and on a resumé, they won’t help the business achieve operational velocity. When there are multiple automation projects competing for the team’s time, it would make sense to do a break-even analysis to obtain better insight on the returns of automating an operational task.

The Agile methods to select and quantify a task such as backlog prioritization and estimating time for a story are not adequate to assess how the organization would benefit from that project overall. The break-even analysis proposed here would help to determine whether an automation project is worth doing by looking at the overall impact of rolling out that automation in the organization. Agile is limited by its narrow focus on the team that rolls out the automation—the DevOps team—and it cannot provide any metrics on the overall impact of an automated process on the organization.

The Break-Even Analysis

Let’s define various metrics involved first and then do the simple math of overheads and breaking even with the benefits.

Development time (d) – This is the time needed to develop and roll out an automation task. This would be same as the time estimate used for a related story in an Agile sprint. In hours.

Maintenance time (m) – As any experienced DevOps engineer can attest, developing a script or tool suite is not a one-time deal. The changes will be needed due to many factors:
- Infrastructure change.
- Fixing bugs in the tool.
- Enhancement requests.
- Training users of the tools, such as SREs and fellow team members.
Budget the hours needed annually for this task, depending on the complexity and possibility of changes down the road.

Manual working time ™ – The time needed to complete the task without automation. Doing things manually can cause human errors which adds to the total time. Factor that in the estimate if this task has been causing issues. In hours.

Automated working time (ta) – The time needed to complete the task using automation. In hours.

Jobs count (c) – The number of times this task is run. Make an annual estimation so even infrequent operational tasks can have a score.

Though arbitrary, my suggestion is to try out an automation for a year for its benefits. Check if the project would bring in impressive returns during that time frame:

Project overhead = d + m

Savings from automation = (tm – ta) x c

Net benefit to organization = Savings from automation – Project overhead

To embark on an automation project, the organization should benefit greatly from it to do things faster and better. While an Agile way of prioritizing an automation task would narrow the focus only on the DevOps team, this method also gauges and factors in the users’ time.

DevOps Benefiting Customers

The tools developed might not be used internally always, which is a major assumption in the above break-even analysis. It is quite possible that an automation process could benefit end users as well. I think it is very important to factor in the time saved by our customers also.

Happy customers always bring in goodwill to a company.

— Thomas Theakanath
February 13, 2019
Actifio Looks to Meld DataOps with DevOps

Actifio and IBM have formed an alliance under which IBM will make available data management software developed by Actifio under its own name as part of an effort to close the gap between DevOps and DataOps.

At the same time, Actifio will make available a software-as-a-service (SaaS) offering for the first time, dubbed Actifio Go, which promises to make it easier to manage and move data across multiple clouds.

Actifio CEO Ash Ashutosh said with the rise of both DevOps and DataOps there is now a unique opportunity to unify the management of pipelines across the enterprise. While storage administrators have been creating data pipelines for databases and applications for decades, the pipelines developers create to consume that data have been developed and managed separately. Now there is a nascent DataOps effort based on a set of best practices for automating the management of data that borrows many of the same principles being advanced by DevOps proponents for the building and deploying of applications.

Actifio’s core Virtual Data Pipeline technology advances DataOps, Ashutosh said, by making it easier to copy a virtual instance of a data set running in a production environment and update it with the most recent copy of that data at any point in time. That capability is not only being employed to, for example, copy data into the cloud, but also to make data readily accessible to DevOps teams as needed on a self-service basis, he said, adding the goal is to make it easier for developers to dynamically consume the latest version of any data set as needed, with a minimal amount of intervention required on the part of a storage administrator.

IBM plans to make an instance of Virtual Data Pipeline available as part of the IBM InfoSphere portfolio of data management software it provides. That agreement extends Actfio’s existing reseller relationship with IBM.

Ashutosh conceded there is much work to be done before DataOps becomes a natural extension of DevOps. Most storage administrators today are not all that familiar with how the data pipelines they create are consumed by applications. Most storage administrators continue to think in terms of volumes and files rather than in terms of managing data pipelines, he said.

But as those application environments become more dynamic thanks to the rise of microservices, pressure to modernize data management will only increase, Ashutosh noted. For example, more DevOps teams will be integrating the ability to copy data directly into their continuous integration/continuous delivery (CI/CD) platforms. Achieving that goal will be easier if the software employed to manage data within the context of a DevOps processes is invoked as a SaaS application, he said.

Most IT organizations are a very long way from melding DevOps and DataOps. Most are still struggling with mastering the fundamentals of DevOps. But the convergence of DevOps and DataOps is all but inevitable. The only thing that remains to be seen is the degree to which IT organizations will proactively seek to achieve that goal versus waiting for developers to force the issue.

— Mike Vizard

February 12, 2019
Help a Student Out and Advance DevOps in Academia

Those of us who attended university know the pressures students face every day. Between attending classes, completing homework, figuring out what they really want to do with their life and all of the other assorted adulting they have to manage, college students have a lot going on. That’s why a little help can go a long way.

Take Gabriel Cogo, for example. He’s a Ph.D. student at Texas Tech University in the Management Information Systems Department. He is working on his dissertation, the topic of which is DevOps, mostly focusing on the organizational impact and the factors that lead to successful DevOps adoption by organizations. He needs to gather information from DevOps professionals, such as IT analysts and managers, and reached out to DevOps.com to see if we could help spread the word.

From Cogo’s letter:

… DevOps is an important topic, but so far not very much research has been done to help us understand how it works in actual companies.

We ask that you participate by completing this survey. Additionally, if possible, I ask that you forward this survey to other colleagues in the IT department, preferably from different levels in the company (e.g., analyst, manager, CIO).

This is an online survey that can be taken on your computer or smartphone, and we anticipate that it will take no more than 20-30 minutes to complete.

This survey is completely anonymous, and we will only ask for the optional name of the company, so we can better understand the characteristics of our sample. To participate in this research please click the link:

http://ttu.az1.qualtrics.com/jfe/form/SV_3z5Oh7ApF1za1pz

You are free to leave at any time. We greatly value your participation in this study.

For those interested, Cogo has shared with us the executive summary of his dissertation, which is available here.

So whaddya say, want to help a student out?

— Charlene O’Hanlon

February 12, 2019
Death of the Release: The Move to Continuous Delivery and Experimentation

As we move from continuous delivery to continuous experimentation, we also must develop new practices

As software development processes have evolved, we have mostly said goodbye to the idea of defined product versions. Many modern product delivery teams are taking this a step further—even the concept of a “product release” is starting to fade. Instead, products are becoming a fluid, rapidly evolving set of features, assembled uniquely for any given user.

Twenty-five years ago, the new release of a software product was a notable event. The marketing department would even insist on a catchy version name for the release. Internet Explorer 6, Office 2000, Windows XP, OSX Mountain Lion. This is still the case for a few types of software—operating systems being the most notable—but for most of the software products we use daily the concept of a version has faded away. What version of Google Maps are you using these days? How about Facebook? Twitter? As far as the end user is concerned, there is no version, just “current.”

A few different forces have moved software products away from release versions. The rise of agile software methodologies and associated practices such as continuous delivery has allowed software teams to tighten up software delivery cycles dramatically. Products that once were released every few months are now updated every few days.

In parallel, the growing capabilities of the web as a platform has moved many products off of the desktop and into the browser. This has greatly reduced the friction involved in releasing a new version of a product. Pushing a code change to servers you manage is a lot easier than persuading your users to download and install an update.

Finally, there has been an architectural shift away from large monolithic systems toward service-oriented architectures and, in recent years, microservices. These modern architectures consist of many small, independently deployable units. This again reduces the friction around deploying a code change by reducing the scope of the deployment to one specific service.

These forces combined have led to software release cycles shortening dramatically, from multiple months or years between each release to a rate of weekly, then daily, then hourly software delivery for some teams. Delivery of a new software release has moved from a marketing event with fanfare to something that is happening almost continuously, even for large products. As far back as 2011, engineers at Amazon were releasing changes to production every 11.6 seconds.

As teams move from a monolith to microservices there is no longer one deployable unit, but rather an ecosystem of independently deployable services. It no longer makes sense to ask which version of a release is running in an environment. Instead, we must ask which version is running for each individual service.

And then there’s feature flagging. One can think of a feature-flagged service as existing in a sort of quantum superposition of potential code paths, resolving to a specific set separately for each request. This means that a service’s behavior in an environment can change radically without any code deployment and without any observable change to the release version.

Now, as we move from continuous delivery to continuous experimentation, we are reaching the point where it is no longer useful to attempt to describe the current running software in terms of a “release,” or even a set of releases. The situation has become a lot more fluid.

Coping in a Post-Release World

Modern approaches like microservices and continuous experimentation are a boon to product delivery teams. They allow us to move faster with more safety, thanks to the tight feedback loops they enable. But this new world also brings challenges.

It can be a lot more difficult to diagnose a bug when you are not sure what code was involved. The load on testers becomes greater as they need to consider the interaction between multiple releases of different services—each with different feature flags which can behave differently from request to request.

From a user’s perspective, a product’s rapid pace of change can be a little overwhelming. New features arriving frequently is nice, but having the UI change every time you log in can be disorienting. Even worse is when a feature is available one day and then gone the next. Users can also be wary of the idea that they are not getting the same experience as other people, particularly if there is any whiff of unfair business practices.

Ironically, while this accelerated feature delivery is partly enabled by continuous experimentation practices, that same speed of change can itself interfere with feature experiments. It can be difficult to statistically correlate an uptick in a KPI with a feature experiment when there are other changes happening over the course of the experiment.

Enhancing the observability of your software—the quality of logging and other instrumentation—is one key way to mitigate some of these challenges. Another is keeping the number of active feature flags reasonably low, which can help on a variety of fronts. It reduces the testing burden of multiple interacting flags, as well as the risk of experiments interfering with one another. Fewer active flags also mean fewer things changing at once for your users.

Managing all feature flags in a shared system can help in understanding the number of active flags and avoiding interfering experiments. Centralized flag management also means you can batch up a set of feature changes into a single release, which helps avoid overwhelming your users with many small changes. A centralized system makes it easier for testers to see which flags they should expect to be in play within different systems, and how those flags might interact.

We’re entering an era that will involve a massive explosion in the rate at which we release new experiences to our users. Embracing this next stage in the evolution of product delivery can enable teams to move faster and with greater safety. But entering this brave new world requires us to develop new practices if we are to avoid the pitfalls of a post-release world.

— Pete Hodgson

February 11, 2019
DevSecOps Implementation Process and Road Map – Security at Every Step

DevSecOps is changing our perspective toward security and is equipping us to deal with its challenges in an intelligible manner. The systematic approach of DevSecOps helps us add value to our business processes while ensuring security.

Here’s a summary of the key inputs and a recipe for a successful software development project. Implementing DevSecOps with the primary goal of enhancing security requires a step-by-step procedure.

It requires the unification of culturally disparate teams of Security, Operations, Development and Test for the sole purpose of building a product marked by quality and backed by security.

The DevSecOps process will require effective planning, design and release, which will be put together with a collaborative toolchain of technologies to bring about a common goal.

Furthermore, as organizations continue to rely on automated delivery, avenues are created for testing opportunities beyond traditional bugs. In-house experts will be able to identify potential loopholes, design errors and even code weak spots.

Being able to identify weak spots and flaws well in advance helps organizations maintain a competitive front in the market and trustworthiness before its target audience.

DevSecOps Implementation Process and Road Map

1) Planning: Planning is the first approach to any task at hand and the core focus of DevSecOps—security—begins from here. In the planning stage, DevSecOps professionals must go beyond creating feature-based descriptions. The focus should also be on security and performance, acceptance test criteria, application interface and functionality and threat-defense models.

Tech terminology: Acceptance Test Criteria is used by DevSecOps professionals to understand user preferences and behavior to a software application behavior.

2) Developing: Developers should approach DevSecOps with a “how to do it” approach, rather than a “what to do” approach. It is important for developers to bring together available resources for guidance, have reliable practices and a code review system in place for themselves and for others in the team to follow.

3) Building: Automated build tools can uplift the whole DevSecOps implementation process tremendously. These tools ensure test-driven development, standards for release artifact generation and utilize tools to ensure the design aspect is in alignment with the team’s coding and security standards through statistic code analysis.

They can also be used to identify vulnerable libraries being used in your application and replace them with new ones.

4) Testing: Automated testing in DevSecOps should utilize strong testing practices including front-end, back-end, API, database and passive security testing.

Tech Terminology: Passive Security Testing is a developmental stage testing where security testing is not conducted directly on the target.

5) Securing: Traditional testing methods always remain in place in DevSecOps exercise. However, somewhere down the line, there is a tendency to identify issues toward the end of the development process.

Through advanced practices such as security scanning, we tend to become more aware of the issues and can determine if the threat is a serious one or not.

6) Deploying: Automated provisioning and deployment can fast-track the development process while making it a more consistent one. Infrastructure-as-code tools can perform the aforementioned audit properties and configurations and ensure secure configurations across the IT infrastructure.

7) Operating: Regular monitoring and upgrades are the Operations team’s important tasks. DevSecOps teams ensure to deploy infrastructure-as-a-code tools to update and secure the entire organization’s infrastructure in a quick and efficient manner with no scope for human error. Operations personnel have to be especially watchful of zero-day vulnerabilities.

Tech Terminology: Zero-Day vulnerabilities are a software breach that remains unknown to software productions personnel and can eat away at a computer program and other components such as a network.

8) Monitoring: Constantly keeping a watch for irregularities in security can save an organization from a breach. Hence, it is essential to implement a strong continuous monitoring program with real-time to keep a track of system performance and identify any exploits in their early stages.

9) Scaling: Gone are the days when organizations spent precious hours and money on the maintenance of large data centers. With the introduction of virtualization solutions and the cloud, organizations can scale their IT infrastructure or replace it in the event of a threat, which would be impossible to do with a traditional data center.

10) Adapting: Continuous improvement is key to any organization’s growth. An organization will only be able to achieve the desired growth of it evolves in its practices including DevSecOps practices—security, functionality and performance. Therefore, an organization should adapt to continuous improvement and external changing trends.

The DevSecOps is in itself a process of innovation that substantially adds value to an organization.

Point to Remember: Security is everyone’s responsibility.

— Veritis

February 11, 2019
CXOs Overestimating DevOps and Continuous Testing Maturity
More work is needed to achieve continuous testing, Forrester report shows

Forrester recently completed an interesting new research project exploring what separates DevOps leaders from DevOps laggards. After analyzing data collected from 603 global enterprise respondents responsible for their firms’ DevOps strategies, Forrester learned that firms with the most mature DevOps practices do several key things differently:
1. Allocate proper testing budgets and focus on upgrading their testing skills.
2. Implement continuous testing to meet the demands of release frequency and support continuous delivery.
3. Include testers as part of their integrated delivery teams.
4. Automate end-to-end functional testing.
5. Shift left testing to earlier in the development life cycle.
Firms who follow these five best practices experience testing as a way to gain speed and efficiency, rather than a bottleneck to delivering faster.

This was not terribly surprising. On the one hand, study after study shows that testing is the No. 1 bottleneck to accelerated application delivery. On the other, we’ve seen firsthand how organizations that commit to transforming testing successfully shift from waterfall-style manual testing processes to automated continuous testing integrated into CI/CD pipelines.

What caught us off guard, however, was CXOs’ highly inflated estimation of their continuous testing, DevOps and Agile maturity.

According to the report, only 26 percent of non-CXOs reported that their organization was following all five of these best practices—but 57 percent of CXOs believed that they were. According to the report:

While most Agile and/or DevOps firms have implemented some of these five core testing practices, few have actually implemented all of them — only about a quarter of respondents say they somewhat or completely agree with all five best practice statements.

This is an important distinction. While many CXOs and high-level decision makers believe they are ahead of the pack, our research shows that only the small fraction of firms that follow these best practices have more advanced Agile and DevOps practices compared to their peers — and their behaviors and attitudes support that assertion.

Moreover, CXOs also reported much higher levels of Agile and DevOps maturity across the board than non-CXOs did.

The good news for DevOps professionals is that CXOs are your champions: They believe you’re doing a great job! The bad news is that, at some point, you need to tell them about the gaps that currently exist in the process. You also need to collect and share some of your own data to make the case that actually adopting these five proven best practices will help you increase delivery speed while reducing business risk.

Detailed Report Findings

This was just one of the many interesting findings from research project, which was led by Forrester Vice President and Principal Analyst Diego Lo Giudice.

As a high-level summary, the research uncovered the following:
- Understanding of business risk is the most important determining factor of DevOps and Agile maturity.
- Experts focus primarily on contextual metrics (e.g., requirements coverage) while others focus on “counting” metrics (e.g., number of tests).
- Experts are more likely to measure the user experience across an end-to-end transaction while others rely on application-specific or team-specific metrics.
Detailed results and analysis are available in the complete report: “Forrester Research: What Separates DevOps + Agile Leaders from Laggards?”

Report Methodology

In this study, Forrester conducted an online survey of 603 enterprise organizations in North America, Europe and Asia Pacific to evaluate current software testing practices and metrics tracked during survey development. Survey participants included decision-makers and individual contributors responsible for their organizations’ Agile and/or DevOps development strategies. Questions provided to the participants asked about their firms’ attitudes toward software development automation, risk management and testing practices, as well as the metrics they track and value in the software development life cycle.

— Cynthia Dunlop
February 8, 2019
Fail Fast: How Shifting Security Left Speeds Development

How DevSecOps can help organizations increase security, move faster and save money

With developers under constant pressure to create more software in less time, the last thing you need is for your code to fail at the end of the development lifecycle. No developer wants to create inoperable or insecure code.

We know that most software products reach the market with flaws or vulnerabilities. On average, more than 85 percent of all software applications have at least one vulnerability, and more than half of flaws remain unaddressed for one to three months after first being discovered.

The sooner a developer can identify, view and correct a flaw, the more efficient it becomes to fix in the software development life cycle (SDLC). That is the underlying philosophy of DevOps. Despite the somewhat negative connotation, failing early in development can be beneficial in deploying software to market more quickly.

The most advanced organizations today employ a DevSecOps model, which tends to incorporate more frequent security scans, incremental fixes and faster rates of flaw closures into the SDLC. More importantly, it allows security teams to shift left to test software products against security standards earlier in the development process.

According to Gartner, more than 80 percent of development teams will implement DevSecOps by 2021. In 2017, that number was around 17 percent.

In Veracode’s latest “State of Software Security” report, we discovered companies that adopt a DevSecOps approach to development are addressing software vulnerabilities more than 11 times faster than companies that use a more traditional software development method. In the process, DevSecOps companies are innovating faster, saving money and becoming more efficient in how they identify and resolve new risks.

By integrating developers with IT operations and focusing everyone on making better security decisions, DevSecOps can help deliver safer software with greater speed and efficiency.

Introducing security earlier in the development process creates a sort of blueprint for teams to build within the specifications of major IT regulation and helps reduce risk by fixing vulnerabilities before they can be exploited. Think of it like building an apartment complex according to city codes with inspectors integrated in the construction crew.

In practice, DevSecOps can add some friction and hinder the development process. Traditional tools for testing code and assessing application security risk simply weren’t built for the speed that DevOps testing requires.

To make DevSecOps successful, development teams need to start with automated testing tools, as relying on manual processes can’t possibly keep pace with accelerated development timelines. Tools that can be used in an integrated development environment (IDE) are key, as they allow developers to integrate security into their workflow rather than having to launch a new environment whenever they need to test code. Solutions that check for flaws during the coding process enable developers to address vulnerabilities early on when fixes are the most cost-efficient. And because DevSecOps is equally concerned with security when software is in production, development teams need tools for testing applications after release. Development teams, meanwhile, must be comfortable with changing the way they work.

Business leaders must recognize the importance of integrating security with development and communicate that priority to development teams. New regulations such as the EU General Data Protection Regulation (GDPR), which can fine companies up to 4 percent of their revenue for failing to disclose processes related to data breaches, are now in place. All businesses must be motivated to operate with a security-first mentality that permeates through the business, including within development teams. Veracode data shows that customers taking advantage of DevSecOps’ continuous software delivery are closing their vulnerabilities more quickly than the typical organization.

DevSecOps doesn’t always require security personnel to be physically involved in the development process. Companies can and should train developers on basic security techniques and offer security resources to help developers become responsible for the security of the software they build.

As the DevOps movement has unfolded, security-minded organizations have recognized that embedding security design and testing directly into the continuous software delivery cycle of DevOps is necessary. This is the genesis of DevSecOps principles, which offer a balance of speed, flexibility and risk management for organizations that adopt them.

— Mark Curphey

February 8, 2019
‘DevOps Engineer’ Title Lands in Top 5 of Dice Salary Survey

The position of DevOps Engineer is gaining some serious respect, and with that comes cash.

In Dice’s recently released “2019 Tech Salary Report,” DevOps Engineer now ranks in the Top 5 of all tech salaries, with an average of $111,683. The survey is based on the responses of 10,780 technology professionals conducted between Oct. 22 and Dec. 13, 2018.

It’s the first time that the title of DevOps Engineer has appeared in the Top 5, according to Dice. The one caveat is that the position might not be as popular as the annual salary suggests; rather, more professionals now identify with this position.

What it does mean is that the DevOps Engineer title is now ranked with more established tech titles, including senior leadership positions CEO, CIO, Vice President and Director, with an average salary of $142,063; System Architect, at $129,952; Tech Management, including Strategist and Architect, at $127,121; and Product Manager, at $114,174.

Overall, the average salary for tech workers remained relatively flat year over year. In 2018, the average salary totaled $93,244, a less than 1 percent increase from 2017, when the average salary stood at $92,712, according to Dice.

In an email, Dice CTO Klavs Miller noted that the increasing use and adoption of various cloud-based technologies is pushing enterprises to invest more in DevOps engineers to take advantage of that compute power to develop new apps.

“Many DevOps Engineer job requirements include a heavy focus on the creation of infrastructure as code, essentially transforming operations into the management of codebases that create infrastructure (in cloud services or native cloud infrastructure rather than servers and hardware),” Miller wrote. “We are also seeing and experiencing first-hand that more and more organizations are moving toward having combined development and operations teams around a domain, rather than splitting along traditional functional lines.”

In his email, Miller noted that while there might be few tech pros that use the “DevOps Engineer” title, it doesn’t mean that there’s an actual lack of engineers with the skills to help enterprises with their DevOps projects.

Instead, it’s a matter of looking for talent that might already be there.

“There is probably a shortage of talent that label themselves as ‘DevOps Engineers,’ but employers should look at the skills required by those roles instead,” Miller noted.

“There’s a growing demand for a skill that is still evolving with market trends,” he added. “As an example, DevOps is not nearly as common as its more common sibling, software engineers, but it has become more popular each year according to our salary survey and among employers who are sourcing Dice for these positions.”

The types of enterprises looking for DevOps talent are varied. Right now, insurance company Geico and hardware store giant Lowe’s are each looking for specific DevOps titles, according to Dice.

If private business isn’t your area, the Louisiana Economic Development agency is currently advertising for an entry-level DevOps position.

In addition to specific tech titles, the Dice report shows that several types of programming languages that are now associated with the DevOps discipline are commanding significant salaries in the market.

For instance, those with expertise in Google’s Golang programming language can command salaries of up to $132,827, according to the Dice survey.

A little further down the line, and keeping with Miller’s emphasis on cloud-based technologies driving much of the DevOps conversation, those with knowledge of Amazon’s DynamoDB and Redshift can command salaries of more than $125,000 on average, the study found.

Additionally, platform-as-a-service (PaaS) skills can net a developer an annual salary of more than $122,000.

In his email, Miller noted that it’s difficult to draw a direct line between needs for certain programming languages and the growing popularity of DevOps. The growing reliance on cloud and the types of digital transformation projects enterprises are engaged with now show how the market has shifted.

“There are some assumptions that we can’t confirm, but DevOps shares programming languages with other roles that are also in demand, as employers adopt cloud-based technology and open source becomes more pervasive in companies’ tech stacks,” Miller added.

— Scott Ferguson

February 8, 2019
How Software Outsourcing Can Empower Digital Transformation

Businesses are constantly readjusting themselves to become more agile and innovative while maximizing their opportunity in today’s digital economy. This is especially true for up-and-coming businesses with limited budgets that need to think ahead of the curve to find additional resources to fuel their digital transformation. Software outsourcing is no longer perceived as a choice or a strategic decision to be made, but rather an operational duty of the IT leaders trying to transform their organizations.

Software outsourcing businesses often adapt better to the evolving digital landscape. Why? Because they aren’t afraid to look outside an organization to fulfill all the requirements needed to run a thriving business and cater to customer’s needs. Software outsourcing is seen by business leaders as an effective means of finding a balance between constant budgetary constraints and the need for a digital transformation. But what are some of the more prevalent outsourcing trends and how can they help empower your business’ digital transformation?

Emerging Technologies

The widespread adoption of emerging technologies adds another dimension to our everyday lives—artificial intelligence and machine learning, blockchain and IoT, automated SIEM software and the advancements in cloud computing capabilities. These technologies are skewing the already-blurred lines between our digital and physical worlds and are helping companies bring highly advanced solutions to the fields of business automation, customer management, risk and security orchestration, to name a few.

Keeping an eye on such trends is one thing, but incorporating them into an existing business structure often requires outside expertise. Software outsourcing companies are, by definition, businesses that help other businesses with the development, design, maintenance and testing of their software application and solutions. As such, leading providers in software outsourcing are constantly looking out for the latest tech advancements the market has to offer and craft their much-needed expertise accordingly.

Outsourcing providers represent the important link between the customer’s growing demand for technologically driven solutions and services and the companies trying to provide them. It seems that every business nowadays wants and AI or machine learning-powered answers to their problems. Instead of having to hire a full-time specialist to help them execute a specific task, companies can simply outsource the needed expertise and use their resources on core competencies.

Data Privacy and Security

Advanced software solutions such as AI and machine learning require massive amounts of user data to prove effective. Collecting user data is one thing, but guaranteeing data privacy and security is a whole different ballgame. As the number of cybersecurity breaches increases over time, so does the demand for data loss prevention, data security automation and advanced threat intelligence. The only way for software outsourcing companies to satisfy this demand is to fully comply with security regulations and industry standards.

The General Data Protection Regulation, or GDPR, has standardized the data protection law in the EU, imposing strict rules in regards to the collection, control and processing of personally identifiable information. Outsourcing vendors are now obligated to conduct their security audits regularly and use that information to update their security strategies and meet the new security requirements.

Doing this allows them to determine the most effective policies for data protection and guarantee availability, responsibility and quality of their service-level agreements.

A successful outsourcing agreement cannot be made if your potential partner doesn’t follow the latest security standards or doesn’t have a clearly defined security policy. The best way to protect your business against potentially hazardous data breaches is as simple as looking for outsourcing providers that have security testing in their service offerings. Agency listings and repositories are an excellent place to start, as they tend to provide the much-needed reviews and rankings of potential providers.

Increasing Talent Shortage

Labor markets are having a hard time keeping up with the rapid pace of tech development. Talent shortage continues to be the No. 1 challenge even in the booming areas of the world such as the UK and the United States. A large number of tech-oriented startups enter the market each and every day and staying above the competition requires expert help with highly specialized skill sets.

To combat the increasing difficulties of finding expert help locally, businesses are turning toward less dynamic regions for their software outsourcing needs. Eastern Europe, for example, is far less saturated with tech startups when compared to the United States, yet manages to provide a sizable talent pool, as well as a large number of outsourcing providers to choose from.

Digital Transformation and the Benefits of Software Outsourcing

Businesses outsource expert help when dealing with parts of the digital transformation process for which they have little to no expertise whatsoever. This allows them to close any gap they might have had regarding their digital capabilities and focus their efforts on core transformation objectives. Collaboration is a vital part of outsourcing and, as such, provides valuable information regarding the latest business insights and disruptive technologies.

Outsourcing software leads to a successful DevOps journey. It allows businesses to find providers specialized in the digital transformation process. Some providers offer a multidisciplinary expertise that encompasses AI and machine learning, big data tools, digital mobility applications, scalable cloud solutions and more. Working with distributed engineering teams who already have the necessary domain-specific expertise can result in a faster time-to-market and increased customer satisfaction.

Digital transformation comes with many challenges and software development outsourcing should not be viewed as the go-to solution for every problem. It is one of many crucial parts found in the larger digital transformation framework. Business automation, emerging technologies, the latest security practices and value-added services—these are the cogs in the software outsourcing-fueled machine that is digital transformation.

— Natasha Lane

February 6, 2019
Study: CISOs Need to Take Charge of DevOps Security
A new report from CyberArk looks at the complexity that goes into securing emerging DevOps environments, and why CISOs need to take charge to protect them.

As digital transformation is pushing more enterprises to adopt DevOps to address their needs for better software delivered faster and more frequently, a huge issue lingers over this strategic business shift: security.

While businesses pay a good deal of lip service to cybersecurity, the rush to churn out new software and update those applications means that security is often skipped in the name of speed and innovation. At the same time, InfoSec is seen as a cumbersome barrier to what the DevOps team is trying to achieve.

Despite these attitudes, it’s imperative that security is part of DevOps conversations, and it’s the company CISO who needs to lead that charge.

In a report released last month, CyberArk polled 1,000 CISOs across the globe to assess how to make DevOps more secure and to ensure that the cybersecurity team is talking to the CIO and other executives overseeing the DevOps process to solidify good cybersecurity.

The report, “Protecting Privileged Access in DevOps and Cloud Environments,” actually skips the more trendy term of DevSecOps in favor of a more holistic approach that bakes the security component into the very beginning of the application development cycle.

Brian Kelly, the head of Conjur Engineering at CyberArk, believes that the DevSecOps term limits the ability of CISOs to offer ways to secure application development at the beginning of the process and ensure that updates embrace good cybersecurity practices.

“Some organizations embrace it, while others refuse to use it,” Kelly wrote in an email about the debate over the DevSecOps term. “We do not use the term because it implies that security is a ‘gate’ or ‘phase’ that can be done after development is finished—but before the apps go operational. Security isn’t just a bolt on to DevOps, and this mentality can lead to a lot of broader issues for operation and development teams.”

This means ensuring security is a part of every DevOps conversation, including making it part of hiring, training, road map creation, feature design, architecture, coding standards, code review practices, continuous integration/continuous delivery (CI/CD), operations, monitoring and maintenance.

The CyberArk report makes clear that many of the tools needed to make DevOps successful within the business are a tempting target for cybercriminals looking to burrow deeper into the corporate network. For example, cloud access keys—whether for AWS, Microsoft Azure or Google Cloud Platform—can open a wide range of company data for threat actors to steal.

The Uber data breach of 2016 started when the company’s AWS access keys were compromised.

Other targets include CI/CD tools for configuration management, including Puppet, Chef and Ansible, as well as tools for running automated tests and builds and this can include Jenkins and Bamboo.

Another red flag for security teams and CISOs is GitHub, since developers tend to have multiple accounts, and can sometimes mix code from personal and corporate projects. A cyberattack using brute force methods can sometimes leave code exposed. Since many developers cook some secrets into the code, such as database credentials, this can expose company and customer data.

“[GitHub] hosts most of the world’s code for modern projects (and almost all open source projects) so any security mistake they make will have wide-reaching consequences,” Kelly wrote. “Up until now, they’ve been able to sidestep many issues by just being a hosting provider for repositories and leaving the responsibility to their customers for what they push up there. But they’ve since added more features for collaboration and CI, which naturally make their users want more of a safety net: automated scanning of third-party libraries for CVEs or watching for things like AWS keys being checked in, for example.”

With all of these difficulties, what can the IT and DevOps teams do to increase security? How can the CISO help make security a central part of the app development process? Kelly offered some practical steps enterprises and their leadership can take:
- Engage security teams early in the development cycle. This helps identify security issues early in the process.
- Use a security-policy-as-code approach to have the Dev, Sec and Ops teams communicate efficiently and unambiguously. This means that new applications or microservices would declare their security policy requirements within code. It gets checked into source control and is as much a part of the application’s code as its internal implementation.
- Decomposing large applications into smaller microservices, each with their own security policy.
- Reducing the “batch size” of changes as much as possible, enabling the security team to work on a smooth, predictable flow of small items.
- Getting end-to-end early to mitigate the risk the ongoing upgrades of components and modules.
At day’s end, while CISOs need to lead the security charge when it comes to application development and delivery. At the same time, DevOps isn’t a fad, and will remain part of the enterprise for a long time. Security leaders need to do some embracing of the trend, too.

“If CISOs want to remain relevant, they will need to see DevOps as a model that they have to align with, not against,” Kelly wrote. “Recent history shows us that large, org-wide DevOps initiatives rarely get shut down once they start, so a successful CISO will build bridges to the Dev and Ops groups and work with them to apply visibility controls and security oversight in ways that don’t cripple their speed. A failing strategy would be for the CISO to resist that sea change and instead try to be a gatekeeper and hold up inevitable progress. The only progress they’ll likely see will be in the speed of their replacement getting hired.”

— Scott Ferguson
February 6, 2019