Why do developers adopt or reject cloud technologies?

In the nearly fifteen years since Amazon AWS cracked open the cloud market by releasing S3 – and changed the world by doing so – there has been huge growth in the variety of cloud solutions available for developers to use. We examine the different reasons that developers give for adopting or rejecting cloud technologies. The findings shared in this post are based on the Developer Economics survey 19th edition which ran during June-August 2020 and reached more than 17,000 developers in 159 countries.

Of the new cloud technologies which have appeared over the last fifteen years, containers have arguably had the greatest impact. With 60% of developers using this technology, the benefits are clearly widely recognised. However, with just under 30% of developers using container orchestration tools and management platforms, there is still room for this technology to develop.

In second position, with 45% of cloud developers using this technology, Database-as-a-Service (DBaaS) is also very widely used, and data storage and retrieval will continue to be an important issue, albeit in a much more sophisticated form than S3 originally offered. Cloud Platform-as-a-Service (PaaS) sits in a distant third place. A third of backend developers are using PaaS, putting this technology slightly ahead of the other ones we ask about – between 21-27% of developers use them.

Why do developers adopt or reject cloud technologies - containers is the cloud technology that is most widely used by backend developers.

Abstraction and simplification are two of the main drivers for the mass adoption of cloud technologies, but we can’t overlook the role that flexibility plays. Spinning up instances to cope with variable demand, creating temporary testing environments, and adding storage as required is immensely powerful. But one often-overlooked aspect of this flexibility is that developers and organisations have the flexibility to choose. They are not restricted to the expensive, bare metal they bought ten years ago, and they are less constrained by monolithic purchasing processes, because, to put it simply, these decisions matter less. In a world where infrastructure can be provisioned and destroyed at will, and where data and server configurations can be transferred easily between homogeneous systems, cloud providers have to find other areas of differentiation in order to compete. Vendor lock-in is much less of an issue for users than it once was, and the rise of the developer as a decision-maker has put even more power into their hands. Note the adoption and rejection reasons for DBaaS and orchestration platforms come from our previous survey, fielded in Q1 2020.

“Pricing and support/documentation are most important to developers”

For every cloud technology, with the exception of orchestration tools, pricing and support/documentation are the two most important factors that developers consider when adopting that technology. For the most part, these two factors switch between first and second place, however, pricing drops to fifth place for developers considering adopting an orchestration tool, whereas support/documentation remains at the top by a large margin. Around three in ten of these developers selected ease and speed of development (32%), integration with other systems (31%), community (30%), and pricing (29%) as reasons for adoption, with pricing being around 15 percentage points lower for orchestration tools than for other technologies. On the other hand, community and scalability are generally more important for developers selecting an orchestration tool.

Much of this distinction is driven by the dominance of Kubernetes. With 57% of backend developers who are using an orchestration tool choosing Kubernetes, it is the single most popular orchestration tool, and importantly, it’s free and open source. It stands to reason, therefore, that pricing is simply not an issue for developers using Kubernetes, instead they value the community support that helps them master such a complex tool.

Indeed, as well as pricing being much less important for these developers, the learning curve is also less important. It seems that these developers understand that they are dealing with high levels of complexity and abstraction and accept that there is a lot to learn in this space. But for those developers that want the abstraction and simplicity offered by a commercial container management system, many paid options exist, and pricing is still an important factor in this space.

Why do developers adopt or reject cloud technologies - Ranking of reasons for adoption

Taking developers’ reasons for rejection into account let us view the decision-making process from the other side. Immediately, we see that pricing is the dominant factor when rejecting every technology. Taking a closer look at the data shows the true extent of this – for DBaaS and Infrastructure-as-a-Service (IaaS), developers were more than twice as likely to select pricing as a rejection reason than the second- and third-placed reasons of support/documentation, and the learning curve, respectively. Amongst the remaining technologies, the smallest difference was 8 percentage points, for developers rejecting orchestration tools.

Further down the list, there is a lot of variability between the different technologies. For example, the learning curve was the second most popular rejection reason for developers choosing IaaS, with a quarter of them doing so. This suggests that the learning curve for IaaS is quite steep and that this is a barrier for many developers. This is not the case for DBaaS however, where only 15% of developers stated this as a reason for rejection.

“Suitability, feature set and performance are hygiene factors”

Suitability and feature set has middling importance for developers choosing to adopt a technology, but for many technologies, it is a more important reason for rejection. This shows that suitability and feature set is a hygiene factor – there are relatively few cases where this is of paramount importance, but many where a technology does not meet the needs and is therefore rejected.

Finally, performance sits very low in the hierarchy for developers adopting and rejecting cloud solutions. This indicates that, for the vast majority of uses cases, the range of performance options provided by vendors is sufficient. This suggests that many cloud computing products are, to some extent, homogenous, and that developers are more concerned with the ‘soft’ features, such as support/documentation, community, or learning curve. These features make for a fulfilling development experience, and in the age of the developer as a decision-maker, experience is everything.

Why do developers adopt or reject cloud technologies - ranking of reasons for rejection.

What are your reasons for adopting or rejecting cloud technologies? You can let us know your reasons here!

Business Community Interviews

Developer Heroes: Amanda the Iron Woman.

Who? Developer hero Amanda Folsom, Developer relations manager

Cross-team communication is incredibly difficult…

[Developer Economics] Hello! Tell us about your role and what you do:

[Amanda Folsom]

I’m a Developer Relations (DevRel) Manager at Nexmo, which is a fancy way of saying I work on an awesome team who helps developers succeed.

What kind of languages do you work with?

DevRel is sort of interesting because I have to know a little bit about a lot of languages and frameworks, but most of my own projects are written in PHP using the Laravel framework. Day to day, I may touch some JavaScript and some Ruby with a little C# sprinkled in.

Developers all over the world are currently taking the SlashData survey. Will you be left out?

How did you get started?

My dad was a developer in the 90s so I grew up around computers. We built my first computer together in grade school and I discovered HTML and JavaScript (the early edition). I eventually moved on to PHP and, at the risk of dating myself here, made a Neopets clone. I still have the original codebase — it was written for PHP4.

How much do you think developers need to focus on specific frameworks or languages these days?

Over the last few years there’s been a heavy shift to framework-driven development. It’s common to see a specific framework or series of tools listed in job posts now. I think it’s important that developers focus on a specific set of tooling as that domain expertise is important, but it’s also important to keep tabs on what’s happening outside of their chosen framework or tool chain.

How much are you involved in buying decisions (in terms of technology platforms etc.) at you company?

As involved as I want to be. I have the freedom to pick and choose tools we use but I’m happy to let other people pick tools that work for them.

Do you think that there is a still a separation between developers and other business departments (e.g. marketing etc.)

Definitely. Cross-team communication is incredibly difficult and historically engineering teams and marketing/sales teams have different goals. Marketing and sales want to sell something (sometimes things that don’t exist yet) and I think it’s hard for them to understand why that makes developers uncomfortable. On the flip side, I think it’s hard for developers to understand how sales cycles work. Sometimes it takes months to close a deal, and the features that were promised may very well be available by the time the customer is ready to sign up.

Have you worked both Agency and Client-side?

Yep! Before working for companies I ran my own consultancy.

What are clients asking for right now in the world of cloud communications?

A lot of folks are just using SMS for 2FA, status updates, etc., but I’m starting to see people use IVR for more contextual phone menus. For example, if a customer calls in from a known phone number, you can look up their record and see if there are any outstanding issues related to their account. People are also looking for other ways to interact with their customers via mobile applications beyond sending and receiving texts and calls. In-app messaging is growing fast.

What projects are you working on right now?

For work? Mostly client libraries for our APIs and some data dashboards. In my spare time I manage a DNSBL and make various dinky web apps.

How helpful do you find developer surveys? [e..g. SlashData report – which seeks to help developers to make better business decisions, with salary benchmarks, trends, programming languages, framework choice etc etc]

They’re hit or miss. Some surveys are very well done while others have an obvious lean in favor of a specific tool or language. Salary benchmarks are also hit or miss because there’s a disparity between large company salaries and startup salaries. There are people who expect $200k+ at a bootstrapped startup simply because one of the large players would give them that much. At the same time, many of these salary surveys don’t factor in other benefits some of the startup folks get like equity, catered lunches, off-sites, and so on.

Do you think developers sometimes undersell themselves?

Absolutely. Imposter syndrome is alive and well in this industry, and people are overworking themselves to stay competitive and keep their skills sharp while actively stating that it’s not enough. The reality is that if you’re scheduled to work 40 hours and find yourself needing to work 80 there’s a time management problem somewhere. Either at the individual level or the management level.

So where do you go to get tech-related news?

A combination of Twitter, Hacker News, various Slack groups, some email newsletters, and mailing lists.

What’s going up and what’s going down in your industry?

Oddly enough, voice comms are trending upward. We’re seeing a lot of SMS activity still, but more people are starting to include voice services in their applications too.

What do you think the future looks like in terms of IaaS vs PaaS vs Containers vs Serverless?

This tweet about sums it up for me:

Right now we have a ton of tools designed to help people scale and distribute their applications, but everyone is still running into scaling issues. With serverless/IaaS/PaaS architecture, you run the risk of vendor lock-in with an inability to port your code outside of a specific platform. Containers solve some of the portability problems while introducing other problems with storage and performance. There’s no doubt that many people still find utility in these technologies, but many organizations seem to be transitioning back to bare metal servers or hybrid clouds.

Are you working on the projects you would like to work on?


Do you have a favourite superhero?

Iron Man. I have a collection of 1st edition Iron Man comics :).

Take SlashData’s developer survey and win some amazing prizes for your testing needs, including Pixel 2 5″ 64GB and an iPhone X.