devopsy.kinsta.cloud

Tag: developers

What Developers Really Think About Pentesting

A developer in their natural habitat is often spotted in a state of deep concentration, coding awesome features to tight deadlines. Feature-building is often our favorite part of the job, and really, it’s the fundamental outcome of the software development life cycle (SDLC).

However, as we have discussed before, many of us are still prioritizing features over security best practices. After all, in most organizations, it is set up to be someone else’s job and adequate security training for us is limited. Penetration testing and static analysis scanning tools (SAST) are just part of the overall process to mitigate security risks, operating rather independently from what we do — until the code bounces back to us for hotfixes, of course.

It’s at that moment that many developers think, “Do the pentesters hate me?”

These interactions often define a team and culture. The concerning thing is, the lack of communication, understanding and overall collaboration has created tension, at least on the side of the developer.

Think about it: Imagine you’ve spent a few hundred hours sculpting a marvelous statue, and then someone comes along with a hammer and starts smashing bits off it after they’ve told you its foundations are not up to scratch. That’s the perceived dynamic between a tester and developer — the latter has their software darlings slaughtered by an outsider that hasn’t labored through the process with them; instead, they’ve extended the workload and delayed the satisfaction of shipping code.

Having moved into the security space long ago, I can see both sides of the story. And no, pentesters don’t hate developers. The pentester is in all likelihood, overworked and under a lot of pressure. As such, a constant stream of common security bugs that could be quite easily fixed at the code level take up time, resources and headspace away from the really serious issues.

I always saw pentesters as kind of like parents. They want you to do well, and when you don’t they’re not mad, just disappointed.

Now that I’ve put that (perhaps slightly unfair) image in your mind, let’s explore this a little deeper. What has caused this world view among developers?

Resentment for Being Told What to Do

Nobody likes feeling as though they’ve done a bad job, or that someone doesn’t like their work. Sadly for developers, when static analysis and pentest results come back to them, it can feel like a report card. They’ve been given low grades, but at the end of the day, their bosses assess them on the features they’ve built and the time they’ve delivered them, not whether there were vulnerable elements in the software or not.

For the poor pentester, this is a case of “don’t shoot the messenger.” It’s nothing personal — they are tasked with finding bugs, and they found them. Granted, at a person-to-person level, maybe some pentesters are grumpier than others, but they’re not (or shouldn’t be) out to crucify development teams. It would be far easier for both teams if they were on the same page with what constitutes security best practice. Developers are not expected to be perfect; realistically, the testing team is there to protect them from shipping vulnerable code.

Minor Issues vs. Higher Priorities

It’s true, a developer’s highest priority will always be the building of features, and in this crazy world of rapid digitization, it will have to be done at speed. While some coders have a personal interest in security and secure coding, the general sentiment is that security is “someone else’s problem,” which inevitably includes pentesters.

Most common vulnerabilities are indeed minor issues to remediate — once known, the fixes are simple to execute for things like cross-site scripting (XSS) and SQL injection. The problem is, many developers don’t realize they’re introducing them in the first place, and these seemingly minor issues are the small window of opportunity an attacker needs to cause devastating problems for a company. According to Akamai, between November 2017 and March 2019, SQL injection vulnerabilities accounted for 65% of all web-based attack vectors. For a vulnerability that has had a known fix for more than 20 years, that is a sobering statistic.

Some pentest teams do assist in the remediation of security bugs, but others will provide a report of the bad news and expect developers to work through hotfixes, even if they have moved onto a different project by the time this happens. And in some cases, the development team may be faced with a report that includes bugs they can’t (or shouldn’t be expected to) fix. It still has to be part of the findings, and again, not taken personally.

The “happy medium” for this would be pentesters, security personnel and development managers acting in more of a mentor role to ensure the team has what they need in terms of effective training and tools, giving individual coders the best chance to succeed and code securely from the very beginning of the SDLC. Both teams really should be meeting half-way to ensure security is considered from the start, as part of a healthy DevSecOps practice.

Lack of Knowledge vs. False Positives

Static analysis is an element of the security process in the SDLC, and static analysis scanning tools (SAST) play a fundamental role. And yes, false positives are an issue with these and other types (DAST/IAST) of scanners. It’s an annoyance in what is already a slow process, requiring manual code review and putting pressure on both developers and pentesters alike. Pentesting personnel have taken time to meticulously set up custom rules to avoid inaccurate readings and provided company-specific guidance, yet some false readings slip through and end up in front of a head-scratching developer.

This process isn’t perfect, but the other problem is that many developers lack enough knowledge to mitigate a lot of common vulnerabilities on a consistent basis. With security training rare in tertiary education, and on-the-job training varying in its effectiveness, it stands to reason that there may be some overconfidence at play as well (and it’s not their fault, we as an industry need to get better at equipping them with what they need).

Remediation Tasks

Sometimes, there is an assumption by overworked engineers that pentesters are just hanging in the wings, waiting for the moment to strike by testing an application and raining on the development team’s parade. They are over-testing, they’re nitpicking, they’re creating extra work.

The only problem with that is they, too, are overworked (more so, in fact, the cybersecurity skills shortage is at dire levels and getting worse) and simply don’t have the time to test without reason. They are not the sole decision-makers in prioritizing testing; it could have been requested by senior leadership, a customer, as part of a security audit or even determined as a result of a bug bounty program.

For a developer, being pulled off current feature-building sprints to work on security fixes is annoying — especially if it’s not their work. Perhaps a previous team did the last update, or another vendor. However, security is everyone’s problem. That doesn’t mean every developer has to take ownership of security bugs as though they have made them all themselves, but they do need to come to the party in terms of security being a shared responsibility.

Where to from Here?

Sometimes, a mindset shift can be all it takes to make significant headway in solving a problem. We’ve talked about the rather frosty reaction a developer has to less than favorable pentest results, but what if they could turn it into a challenge? Perhaps they could think of the pentester as a friendly competitor; someone they can beat at their own game. After all, a security-aware developer that can eliminate common bugs as they write code is going to make their job much more difficult. By contrast, a developer with no focus on security is going to be comprehensively bested by their pentester counterparts when they can easily break their software.

Pentesters and developers may not be joined in harmony 100% of the time, but their relationship can be vastly improved when an organization addresses security as a key priority, and empowers teams with the right knowledge and tools to succeed — especially developers. It comes down to whether a company-wide, positive security culture is a priority, and if we are to fight the (currently) losing battle against common vulnerabilities, it absolutely should be.

June 17, 2020
Using this Time to Optimize Your Dev Team’s Workflow

As Andy Warhol once said, “They always say time changes things, but you actually have to change them yourself.” This more than ever resonates with the change that companies have found themselves experiencing of late. The more the world embraces digital methods of work, the more that change becomes paramount to a successful workflow. It is crucial to adapt, whether that means throwing out the old or bringing in the new — or a mix of both.

The current global pandemic has forced companies to reconsider how they operate, and it’s no different for their development teams who now find themselves distributed. So the question becomes: How do you go about using this time as an opportunity to optimize your team’s workflow?

By making the necessary changes, you can not only increase productivity, but also make your team happier. As the saying goes, “Happy devs, happy life.” Let’s look at automation, independence and understandability as key components of your digital transformation.

What’s Killing Your Team’s Productivity

The Problem: Too Much Bureaucracy

Being too dependent on management or your colleagues is often a bottleneck at many companies, especially larger traditional ones. When we were all in offices, this problem could be mitigated more easily — but today, things are shifting toward more ownership, and having everyone distributed means you need to be able to get the job done yourself.

The Solution: Shift-Left

Bureaucracy shouldn’t be in place just for bureaucracy’s sake. While the goal of those processes are typically risk mitigation and governance, DevOps advocates have been arguing that modern tools and techniques allow shifting-left much of that burden directly onto developers. Use this time to empower developers to build in alternative safeguards relying on automation, self-service and measurement instead of change boards and forms.

The Problem: Status Meetings

Status meetings are the bane of all developers’s lives. Nobody will argue that they’re not important, but who wants to sit through meetings when you can be spending time elsewhere? — for instance, at your desk, sipping a nice cup of coffee while working on your code and finding that elusive bug.

The Solution: Asynchronous Communications

What used to be done with lots of in-person status meetings doesn’t always translate well to a video conference — water cooler talk just isn’t the same via teleconference. While it’s important to try and maintain that personal touch, it’s even more important to enable asynchronous communication methods as much as possible — both free-form (such as email) as well as structured (such as ticket management). Moving to this new mode of operation requires developers to be more independent. This is another place where automation can play a huge role, formalizing tribal knowledge into scripts and tools, making them easily accessible for all.

The Problem: Lack of Data

How many hours have you spent staring into the great abyss of code, hoping and praying that you’ll be able to deploy soon? You’re not alone, we’ve all been there, done that. Waiting for deployments is par for the course of living life as a dev. The source of this long wait? A small, missing piece of data. And this need for data creates what I like to call the engineer’s dilemma: Is it better to fly slow but have the data I need, or fly fast but perhaps be making worse decisions due to a lack of data?

The Solution: Understandability

Understandability tools allow quick access to data in real time. This results in shorter, more efficient workflows, which in turn improves team velocity and code quality substantially. Understandability is not the same thing as observability. Think of it like this: Observability helps teams quickly identify where a problem is, but you still need a tool that can quickly fetch the data in order to solve the problem. In other words, if data is the new oil, go find the understandability tool that you think is the best drill.

Conclusion

Change is not a concept most like. But now that it’s happening anyway, it creates an opportunity to introduce a healthier, more productive workflow. Grab that cup of coffee and ask yourself: What change would benefit us most? Find it, implement it and watch as your distributed teams become a smooth-sailing ship in no time.

June 10, 2020
Developer Personas, or the Exquisite State of Being of June

June 10, 2020
Who’s Responsible for Security? Apparently, It Depends

More than 10 years after organizations began implementing DevOps, responsibility for security still resembles the proverbial chicken and egg dilemma.

GitLab’s 2020 Global DevSecOps Survey asked developers, security team members, operations pros and testers about sole responsibility for security in their organizations.

About 28% of developers, 33% of security teams, 21% of ops pros and 23% of testers said responsibility for security rested only on their shoulders. At the same time, 29% of security teams said everyone was responsible, nearly as many as said they had sole ownership.

Confused yet? So were many of our survey respondents, who had a lot to say about the fluid – and frustrating – nature of DevSecOps.

“The team is trusted to do its own security research and implementation. We don’t know how good or bad we are.”

“I am the only one who actually cares about security in my organization.”

“I regularly put security suggestions in the box of suggestions, only to be ignored.’”

“There’s a security team, but it doesn’t involve face to face with us, the dev team. So we just run the dev process without counting on them.”

The Blame Game

There’s a long history of developers and security pros not seeing eye to eye. In GitLab’s 2019 Developer Survey security pros were very expressive on the subject of developers simply not doing enough to enable security. Developers were equally unhappy, citing security’s “heavy-handed approach.”

This year, we drilled down further to see if we could understand why dev and sec continue to see the world differently.

Differences between the teams quickly became apparent. According to the survey findings, 65% of security team members told us their organizations have shifted security left. But the devil is in the details, and the details do not really support a shift left.

A solid majority of developers are not running SAST, DAST or container scans, and only about half conduct compliance scans. Even if the scans are run, less than 19% put SAST results into a pipeline report a developer can access. Dynamic application security testing (DAST) fares even worse – less than 14% of companies gave developers access to those reports.

So, developers don’t have easy access to critical data. On the other hand, security pros are frustrated that developers continue to either miss bugs altogether or find them too late in the process. Over half of security respondents (61%) agreed at some level that vulnerabilities were mostly found by security pros (not developers) after code is merged in a test environment (which is relatively late in the process). In other words, when asked how developers find bugs versus security teams, 93% gave developers credit for discovering only 25% or less of the bugs to be found in existing code, leaving three-quarters of the bugs for security to find at a later stage in the process.

And as if that wasn’t sufficiently frustrating, 69% of security team members complained it was difficult to get developers to remediate bugs, even if their organizations included security as a developer performance metric.

How DevSecOps Can Work

Clearly, there is work to be done to get developers and security on the same page, but we are seeing a few glimmers of hope. Security pros are not quite the lone wolves they once were; many told us that DevSecOps has brought a welcome change to their responsibilities. Nearly 28% reported being part of a cross-functional team focused on security and almost the same number (27%) said they were more hands-on and involved in the day-to-day development activities. Almost 23% said they were now focused more on compliance and about 20% said they did not see any changes in their roles.

In perhaps the most significant (and promising) finding, GitLab asked what skills would be most important to a security professional’s future, the majority (almost 28%) said soft skills like communication and collaboration. Interestingly enough, a majority of their developer counterparts agreed with that.

So, while no one agrees just yet on who owns security or even how to prioritize security, it’s encouraging that both developers and security pros realize they need to prioritize communication and collaboration.

At least one respondent reports success in figuring it all out:

“We don’t have separate security, developers and operations; we are DevSecOps (and more).”

June 2, 2020
CTO.ai Launches SlackOps Tool for DevOps

CTO.ai has launched SlackOps, a platform for managing DevOps workflows in real-time via the Slack communications and collaboration service.

Company CEO Kyle Campbell said many DevOps teams are embracing Slack to share updates with one another. SlackOps takes that preference for DevOps a step further to enable complex DevOps processes, also known as ChatOps, to be launched from the Slack command line.

That approach allows any member of the DevOps team to write a workflow once and securely share it regardless of what language is employed, added Campbell.

SlackOps also provides access to a public registry that CTO.ai already makes available for sharing developer shortcuts within a specific community.

Beyond streamlining communications processes across DevOps teams, Campbell said DevOps teams will be able to surface additional insights into workflows using DevOps research and assessment metrics to make them more efficient. SlackOps also makes it easier to onboard new members of a DevOps team, he noted.

SlackOps is deployed as a container on the Slack platform and can be downloaded via the Slack marketplace in a couple of minutes.

The goal is to enable organizations to embrace a lean approach to DevOps that enables them to quickly adjust processes as required, said Campbell. Rather than having to commit to a single tool or platform, developers should be able to advance the overall state of DevOps within their organizations without having to be concerned whether a new tool or platform will disrupt communications across the DevOps team.

It’s too early to say to what degree Slack might emerge as a control plane for managing DevOps processes. It is, however, becoming more popular as a way to communicate across members who employ a broad range of tools. Rather than attempting to force DevOps teams to standardize on a single set of tools and platforms, Slack provides a more flexible means of communicating in real-time that is delivered as a cloud service.

Of course, there are now plenty of alternatives to Slack. It will be up to each DevOps team to decide which communications medium best suits them. However, embedding a DevOps workflow application within a communications platform could serve to make Slack a more compelling option for many DevOps teams. Regardless of the communications medium, DevOps teams should expect to be more continuously engaged with one another. That may prove to be a critical requirement with most members of a DevOps team working from home for the foreseeable future in the wake of the COVID-19 pandemic.

As workflows built around asynchronous email messages increasingly are giving way to real-time communications, the challenge many DevOps teams face is finding a way to embrace that higher level of interactivity without members of the DevOps team becoming overwhelmed by the volume of messages being shared. Making the transition to DevOps was enough of a cultural challenge for many organizations. Inundating DevOps teams with real-time messages, not all of which may be pertinent to a DevOps workflow, needs to be tempered by tools that help identify the DevOps signal within all the noise.

May 26, 2020
GitLab Survey Sees DevOps Gains as Developers Exercise More Control

A global survey of 3,650 software professionals published by GitLab respondents indicates developers are exercising more direct control over IT environments.

More than a third of respondents (35%) said developers define and/or create the infrastructure their applications run on, with 14% actually monitoring and responding to infrastructure events. Additionally, 18% of developers instrument code for production monitoring, while 12% serve as an escalation point when there are incidents.

More than 25% of developers reported feeling solely responsible for security, while 33% of security team members say they own security. A total of 29% said they believe everyone should be responsible for security.

A quarter of respondents said their organizations have been practicing DevOps for three to five years, while 37% said they have been practicing for one to three years. Nearly 60% of respondents said their organizations deploy code either multiple times a day, once a day or once every few days, a 15% increase over the previous year.

Brendan O’Leary, senior developer evangelist for GitLab, said that massive jump in the number of organizations capable of deploying code at faster rates indicates many more organizations are starting to move further along the DevOps maturity curve. For example, the survey finds 70% of developers can now provision their own IT environments.

Well over a third of respondents (38%) said their DevOps implementations include a continuous integration/continuous delivery (CI/CD) platform. Almost 59% of those surveyed use GitLab, while 23% use GitHub and 11% use BitBucket. For builds, 60% use GitLab and 38% use Jenkins. A total of 29% said their DevOps implementations include test automation, while 16% said they have embraced DevSecOps.

Almost 40% of survey takers said they “partially” use microservices, while a quarter (26%) said they fully use them. Well over a third (38%) have also adopted Kubernetes.

Despite that progress, however, the survey makes it clear there is still much work to be done. More than 42% said testing still happens too late in the life cycle. In fact, 47% identified testing as the top DevOps bottleneck for the second year in a row. Only 12% said they have completely automated testing.

When it comes to security, well over a third (36%) find it hard to understand, process and fix any discovered vulnerabilities. About a third (31%) said prioritizing vulnerability remediation is still an uphill battle.

O’Leary said when it comes to security the most challenging issue remains determining what vulnerabilities to prioritize alongside a long list of other bugs and issues that often need to be addressed. Cybersecurity teams all too often continue to send developers a list of vulnerabilities they have discovered with no context, he noted. Many developers are only made aware of an issue after their code has been merged, which O’Leary said makes it more difficult for them to address a specific security issue.

It’s not clear any organization will ever achieve complete DevOps nirvana. However, as organizations become more proficient it’s clear the return on investment in DevOps is starting to be achieved as more organizations deliver code faster. The challenge now, of course, is making sure the right secure code is delivered at the right time.

May 18, 2020
Report: Software Delivery Slowed During Pandemic

A survey of more than 500 IT and development professionals conducted by Atlassian finds two-thirds of respondents have slowed down the frequency of software delivery since the advent of the COVID-19 pandemic.

Patrick Hill, head of reliability process at Atlassian, said while developers may be creating more code than ever while they work from home, IT operations teams working from home are struggling to keep pace.

In fact, the survey finds more than half of respondents (51%) reported incident response times have been slower since they began working remotely. At the same time, there’s been a 73% increase in demand for the digital services being provided, the survey finds.

It’s too early to say to what degree slowing down the application delivery process might be a byproduct of the “new normal.” It’s more likely that IT operations teams need more time to re-engineer processes to return to the software release levels typically achieved prior to the pandemic, said Hill.

In many cases, IT teams may also need more time to shift toward cloud-based frameworks for managing application release cycles that can be accessed from anywhere. Hill said Atlassian has seen a significant increase in the use of its IT management platforms since March. New signups have increased by approximately 125%, he noted.

It’s also unclear to what degree an application release backlog may be building inside organizations. While developers may be launching more projects, Hill said many of those projects may be only to address bug fixes. As such, it may not take that long for IT operations teams to recover from the disruption caused by the pandemic.

Nevertheless, Hill said most organizations are still coming to terms with the human impact of the pandemic. Many organizations, for example, might not decide to bring IT teams back into the office at all. In fact, there may not be any office to return to—many organizations might conclude there is no need, especially if productivity levels have not declined substantially. No doubt many organizations consequently will be closely monitoring application release cycles in the weeks and months ahead to determine to what impact working from home is having on IT productivity.

Of course, not every member of the IT team is cut out to work from home. While many IT professionals may be introverts by nature, there are also a great many distractions at home that adversely impact productivity. Conversely, some IT professionals might even discover they have begun to work longer hours.

In the meantime, Hill said IT managers would be well-advised to focus more on outcomes than metrics. The amount of code being released in a given week is not likely to be as important as making sure the right code is being released at the right time. With more demand than ever for application services, the greater the need there is for DevOps teams to focus their efforts on the components of an application that make the most critical difference to the business.

May 18, 2020
Eclipse Foundation Moving to Brussels

The Eclipse Foundation announced today it will begin to transition its headquarters from Ottawa to Brussels as part of an effort to advance international expansion.

Mike Milinkovich, executive director of the Eclipse Foundation, said with so many open source organizations based in North America, there is a clear need for an open source organization to have a larger presence in Europe. As nearly half of the strategic members that provide funding to the Eclipse Foundation are based in Europe, it made sense for the Eclipse Foundation to take on that role.

The Eclipse Foundation is now home to 375 open source projects resulting in more than 240 million lines of code. Some of the most widely employed Eclipse Foundation projects include the Eclipse integrated development environment (IDE) and Jakarta, which is a follow-on to Java Enterprise Edition platform, previously owned by Oracle. In total, the Eclipse Foundation’s projects represent more than 13 billion Euros of investment.

In general, Milinkovich said contributions to open source projects have accelerated in the wake of the COVID-19 pandemic. Developers who are staying home to help combat the epidemic apparently have more time to contribute to projects. The expectation is by moving to Brussels, more European developers will contribute to projects involving technologies such as internet of things (IoT) initiatives that address industrial use cases, he added.

The Eclipse Foundation plans to establish a new legal entity sometime in July, with personnel relocating or added to a Brussels office over time depending on the nature of the Eclipse project being supported, Milinkovich said.

It’s not clear to what impact being headquartered in Europe will have on open source projects, which are by their very nature global. However, Milinkovich noted most of the recent live events hosted by the Eclipse Foundation have been held in Europe. It may be a while before anyone is attending an IT conference in person, but Milinkovich noted European developers already play a major role in the Eclipse Foundation projects.

Between the Eclipse Foundation, the Linux Foundation and the OpenStack Foundation, there is no shortage of opportunities for developers to contribute to open source projects. Many of those projects count on contributions from developers who work for IT vendors that have a vested interest in a specific project. In fact, many open source projects provide a way for IT vendors to defer the cost of creating a core piece of technology that doesn’t provide differentiated value. Rather than reinvent the wheel, it makes more economic sense to share open source code with potential rivals.

Of course, it’s then up to each IT team to decide whether to employ that open source code themselves versus relying on an IT vendor to provide a curated instance of it under a support contract. Regardless, the total cost of IT would be prohibitively higher right now if it were not for the proliferation of open source software. It’s also worth noting many IT vendors that build platforms on top of open source software would be considerably less profitable.

May 12, 2020
Accurics Makes Infrastructure as Code More Secure

Fresh off raising $5 million in funding, Accurics today launched a platform that analyzes the code employed to manage infrastructure as code for vulnerabilities as well as indicators of drift to create a threat model for cloud application workloads and then, if necessary, automatically roll back cloud settings to their last known approved state.

Accurics CEO Sachin Aggarwal said rather than simply focusing on cloud infrastructure, the startup company’s platform analyzes vulnerability feeds, identity access management (IAM) privileges and other data to detect potential cloud security issues. That analysis can then be shared with third-party security tools to automate remediation, he said.

Once the model is constructed, Accurics then monitors the application workload for changes that introduce risks and generates a topology for each workload in real-time to identify any potential indicators of drift away from the initial deployment settings. If the drift is due to a legitimate change, the code can be updated. If it introduces risks, IT teams can roll their code back to the last known secure posture using a “time machine” capability that Accurics has baked into its platform, he said.

The Accurics platform takes a different approach to cybersecurity—rather than focusing solely on application programming interfaces (APIs) exposed by cloud infrastructure providers, it analyzes everything from the Terraform code used to programmatically install workloads to the container and serverless computing frameworks employed. In the future, Aggarwal said Accurics plans to add integrations with other infrastructure commonly employed in cloud environments, including Jenkins, Bitbucket and GitLab continuous integration/continuous delivery (CI/CD) platforms.

That analysis surfaces violations of common compliance and cybersecurity practices based on Security Operation Center (SOC) 2, General Data Protection Rule (GDPR), Payment Card Industry (PCI), Healthcare Information Portability and Accountability (HIPAA), International Organization of Standardization (ISO), Center for Internet Security (CIS) Benchmark, Amazon Web Services (AWS) Best Practices and the AWS well-architected framework.

Aggarwal said Accurics advances DevSecOps by making it possible for organizations to continuously assess changes within their cloud application environments. Most of the issues involving cloud security today can be traced back to errors made while using tools to programmatically provision cloud infrastructure. The Accurics platform helps developers and cybersecurity teams to collaboratively discover those issues, he noted, adding the overarching goal is to enable both teams to reduce risks by eliminating the most common mistakes that are made in cloud computing environments.

As the relationship between DevOps and cybersecurity teams continues to evolve, it’s become apparent the first issue most organizations need to address when it comes to cloud security is visibility. Most IT teams are concerned about cloud security not because the platforms are less secure than on-premises infrastructure. In general, cloud infrastructure is more secure. However, because of a lack of visibility, it’s not as easy for cybersecurity teams to discover when misconfigurations create a known vulnerability. If that issue gets resolved, much of the resistance to cloud computing generated by security concerns will fade away.

April 28, 2020
Data: The Fabric of Developers’ Lives

We’re living in the golden age of application development. Developers can tap into more resources and enjoy greater flexibility than ever before. Multi-cloud environments offer them the freedom to pick and choose from a wide range of services based on the strengths and offerings of different cloud providers. They have unparalleled opportunities to achieve their development goals.

In this environment, developers must build applications to work across different hosted providers, each with their own unique administrators and requirements. The easiest way to deal with this is to forget about storage, at least in the traditional sense. Instead, developers and the organizations they work for should deploy an underlying data fabric that supports everything they’re trying to do, and every cloud provider they need to do it with.

What Is a Data Fabric?

Put simply, a data fabric is an underlying, cloud-agnostic infrastructure that can enable developers to more easily port data between different clouds. An ideal data fabric is highly scalable—supporting an organization’s big data needs—and reliable.

For a visual representation, think of a big Thanksgiving when you invite a bunch of different people over and you need to pull two dining tables of different shapes and sizes together. You spread a tablecloth over the two tables to make them become one. That’s kind of what a data fabric achieves; it brings two different things together to create a single platform.

Why Is this Important?

Storage-as-a-Service—we hardly knew about it. Thanks in large part to containers, which offer exceptional scalability, simplicity and high availability, the speed of application development has increased dramatically. Developers need to be able to quickly provision their own data, in just the right amounts, to match that velocity. And, like containers, that data needs to be portable.

Provisioning quickly means no more going through storage administrators to get the services they need, which can be a cumbersome and time-consuming process. Solutions like Kubernetes’ on-demand clusters enable developers to procure the data they need when they need it.

The abstraction layer provided by a data fabric can empower developers even further. They can write their own APIs, provision data services as needed and move that data between clouds with ease.

This is particularly important when dealing with cloud providers that offer different services. Sometimes a developer may need a service that exists in one cloud but not another. It’s critical to have an underlying storage infrastructure that enables applications and their data to be transferred as needs require.

What Does this Mean for the Role of Developers?

Today, developers must be IT versatilists and wear many hats. They have to manage storage, understand their businesses’ goals—and, of course, they have to develop. That’s a lot to juggle, so it’s understandable why developers would want something that helps simplify things.

Indeed, having a standardized data fabric can make all of this a bit easier. Developers don’t have to bother their storage administrators with requests; they can quite easily provision storage themselves.

Everyone wins in this scenario. Developers save time, become more empowered and have the freedom to create applications and datasets and more easily apply them to different clouds. Storage administrators can focus less on provisioning and more on other value-added projects. Organizations as a whole can also benefit, since developers will be able to create applications more quickly, allowing companies to bring services to market at a faster pace.

Speaking of the Bottom Line — What Is It?

Deploying a standard infrastructure for data services is critical not just to developers but to enterprises themselves. It supports organizations’ initiatives for scalability, flexibility and agility—all of the reasons that companies are doing containerized application development in the first place. For developers working in multi-cloud or hybrid cloud environments, it makes perfect sense.

April 23, 2020