DZone Research: Obstacles to the Cloud

DZone 's Guide to

DZone Research: Obstacles to the Cloud

To get a better idea of the challenges developers run into in the cloud, we interviewed over 30 cloud industry executives for their takes.

· Cloud Zone ·
Free Resource

To gather insights on the current and future state of the cloud, we talked to IT executives from 33 companies about their, and their clients’, use of the cloud. We asked, "What are the obstacles to the success of developing or deploying in the cloud?" Here's what they told us:


  • Security. Helping the customer deal with the problem internally since it has consumer data. Get ahead of the issue. Need depth of questioning so the customer can hand the issue to the relevant people in the company. 
  • Security. A lack of understanding of the security implications. Customer deployed in the cloud from the start on AWS. Multiple teams were involved. Software developers assumed because the system was running in the cloud it was secure. Did not think about redundancy for the data. Had development and production in the cloud with the same set of credentials. DevOps assumed developers had built in backups. It’s unclear who is responsible for security – there is a lack of understanding and identification of best practices. It’s very easy to take the cloud for granted. So many variants in the cloud there is no clear delineation of responsibilities. While the infrastructure is safer, the provider is still responsible for everything on top of that. There’s an incorrect general assumption that if it’s in the cloud it must be secure. 
  • Data security. Are we breaking laws around the world? Coding. Thinking about resilience. Opportunities to start in the cloud versus moving from on-prem. Help companies make smaller, faster changes to the database. Same benefits of DevOps apply to the database. 
  • Secure connectivity to on-prem, cloud and making it Agile. Most network engineers are not doing crypto. Cloud needs to be encrypted throughout. There is a shared security model between the provider and the subscriber. Encryption and authorization is needed in an automated way. 
  • Security. We have our own internal security rules and apply them to the cloud. Data in transit and at rest is encrypted. Three different service levels depending on client needs/wants. Be least disruptive to the end user. It’s an educational challenge rather than a technical challenge. 
  • Security architectures have become the biggest area of friction when moving to the public cloud. Most information-security teams are accustomed to dealing with data center environments and technology, so rather than embracing cloud deployment best practices, they try to architect using their data center tools. Instead of building loosely-coupled systems that scale horizontally, they try to design a tightly-coupled system and scale vertically. The focus on re-creating a data-center environment ends up slowing down adoption because most of the traditional tools and architectures that are built for data centers don’t translate well and can be real cloud ‘anti-patterns.’ This leaves traditional-minded security teams with a reduced capability to deploy security controls. Everything a company does in the data center, where they have central control and the ability to tap into every network flow, becomes an anti-pattern in the cloud. Another significant issue in moving to the cloud is software license costs. Licenses are a holdover from the days of shrink-wrapped products, and, are often a sign that a company is trying to move the wrong type of technology to the cloud. Charging for each instance of a web application firewall, for example, makes it prohibitively expensive to deploy a WAF with every application. Fortunately, users can now embrace a “license-less” model via the AWS Marketplace metering service; a model that only meters the WAF when it sees production or test traffic. 
  • Understanding the shared responsibility model. No one would leave the server room unlocked, so why would you leave the cloud unlocked? Be able to move between cloud providers. Take hybrid-cloud into consideration. 
  • A lot of engineers can make smart solutions, but the channel and sales need to understand. Great products don’t sell themselves. Change mindset from CapEx to OpEx. There is still concern over the security of the cloud.


  • Data transfer and migration, reliability. Legacy apps. Making it seamless for the end user. Not all data can migrate to the cloud, so you may be doing hybrid until you can recode your front end. Legacy apps hardcoded for 20 to 30 years ago. These are not as easy to move. There are a lot of players to be mindful of. We provide a software solution to make it easier to move. 
  • It’s the data stupid. Because we’re in this major paradigm shift. What the application and use case and it determine the data needs/layer. Processing can be Agile, complex, containerized. DL and file access as part of a single use case.  Understand conformational data layer is critical for the whole organization. 
  • One obstacle that we see as a potential barrier to success in developing or deploying in the cloud is the complexity of synchronizing data for hybrid cloud users. Another impediment includes data ingress and egress charges for companies that have large data sets, such as oil and gas seismic data. Additionally, migrating workflows to work in a hybrid cloud context where workloads could be running on-premise and in the cloud is another potential obstacle for enterprise organizations. Finally, managing authentication, networking and storage between on-premise networks and the cloud can span multiple IT departments and can introduce organization complexity. 
  • 1) Availability. 2) Scalability. 3) Moving data to the cloud is a challenge. Move in steps. Start with the easiest. Email may be first. Ticketing solutions. Moving existing infrastructure is the biggest obstacle. A culture of putting things in the cloud leads to departments starting their own applications in the cloud. Shadow IT pops up.


  • Culture is always the first one. Customers have to think about how to organize teams. Skills and knowledge. Platforms are powerful. Do you have the skills and confidence to do it? How to build the skill to leverage the platform. 
  • One of the biggest obstacles is not having a realistic expectation of public cloud deployments. Many companies have turned to the public cloud for cost savings only to experience sticker shock once they realize the cost of moving the entirety of their infrastructure to the cloud. This is only compounded by the sprawling, democratized nature of the cloud. Without an effective cloud governance strategy in place, the public cloud can be littered with expensive money traps – unused, forgotten about instances, overused resources, etc. Paradoxically, shifting to the cloud can add complexity due to the vast differences between clouds and on-prem infrastructure. Lacking the right tools to manage a hybrid or multi-cloud environment, public clouds can all too easily slide into being just another silo. 
  • Going in without understanding four obstacles: 1) operational guidelines; 2) cultural shift; 3) cost management; 4) lack of skill – employees afraid of what cloud means for them, consolidation (how a company is structured – bringing together silos). It’s about application development, not infrastructure delivery. 
  • Perception. Cloud is pretty stable but has a negative perception of security breaches. Confidence. Then the cost. How hard is it to move existing systems over? 
  • 1) Legacy footprint – proprietary Unix variants. Vendors muddying the water. A lot of complexity with cloud-washing. Have open thinking with an open mindset. Think about how to solve the fact the underlying infrastructure is inflexible. 2) Some of the technology elements themselves. Greenfield is great. For existing brownfield what is the right model for the cloud journey? Need the right expertise, trusted environment, vendors. Have to co-exist. 3) The mindset of the development organization. Developers have to lead to the cloud with architecture. 4) When moving to the cloud and deploy they see DevOps is passé. NetworkOps is what’s important. 5) Having the right kind of model internally, Center of Excellence, chargebacks. Dealing with failure on second, third or fourth iteration. Find early adopter projects. 
  • The perception that cloud is simply like my data center but someone else is worried about managing. It’s not. Requires a different set of skills and way of thinking about infrastructure. The way you interact with the infrastructure in the cloud is very different than managing a data center. Start small with interfaces to master the skills. The real opportunity is not just moving infrastructure it’s using the native services they have built as part of their cloud platform. Powerful compelling services make it easier for you to build applications for your business. 3) These cloud platforms are businesses whose job is to make money. Each is highly proprietary. The way you use Azure is fundamentally different in how you use AWS. It’s a long-term relationship you’re getting into. It’s easy to spend a fortune – turn things off, measure how much you are using. 
  • 1) Ecosystem compatibility. There is a period of time as organizations are moving to the cloud where still need to interact with on-prem. All of the players are committed to making it work. 2) Fear over the lack of control. 3) Realizing operations is in the hands of experts with greater reliability. 4) Role change going on for IT less about infrastructure and more about governance, monitoring, and chargebacks. Friction is in the corporate culture and the change of how work is getting done differently in the cloud than on-prem.


  • The following are the obstacles for deploying to the cloud: 1) The Cloud is evolving so fast, it is difficult to pick the right kind of services for the workload that is being deployed. 2) Governing Cloud Operations, Cost, and Compliance. 3) Ease of lift and shift migration from On-premises to the Cloud.
  • It depends on what kind of application is being considered. Modernization of existing applications brings a slew of challenges and often the best answer is a ground-up architectural redesign — clients need to think hard about how much they want to invest in legacy apps, what their transitional state(s) may look like, and what their longer-term vision should be. For new applications, clients need to consider first and foremost how much they want to build themselves versus subscribe to via their cloud provider — and the longer-term implications of that choice, particularly if they want to be able to switch clouds or balance workloads across clouds in the future. (Storage is often at the heart of such decisions in both categories, either because apps expect certain storage functionality — for example, snapshots powering DevOps workloads — or because data is a limiting factor for multi-cloud deployments.)
  • Using the wrong tools is a big one. Some technologies that you used in your on-premises data center will be the right technology for your cloud deployment. I put VMware in that category, especially for enterprise applications, but also because of VMware’s focus on taking all their software-defined data center innovation and making it the foundation for their cloud strategy. But some technologies that you used on-premise won’t be a good fit for your cloud strategy. For example, we believe that snapshot-based DR technology isn’t the right approach to DRaaS with a cloud partner.
  • At the moment, a lack of knowledge about how to operate and provision infrastructure in the cloud is still required to use and deploy to it. This means application developers are still required to learn new skills or depend upon an operations team to help them do this work. Over time, we expect the user experience for self-service cloud infrastructure management to dramatically improve and reduce the amount of systems engineering knowledge needed to do this job. Until then, the domain of cloud operations continues to be a highly sought-after skill set.
  • Lack of skills and fundamentals.
  • Due to the large scale involved, automation is key! The obstacle is having the resources to develop the tools such as CI/CD in time before deployment — before you reach the point that it’s too much to do manually. There’s a tipping point where you just have to automate.
  • Edge requirements, legacy hardware, and network connectivity are the key factors inhibiting the movement to the cloud. There are also security/privacy concerns in some industry sectors like healthcare and government that are slowing adoption.
  • Stuck in proprietary services. A lot of promises with cloud services but the reality is at certain levels you have to work around limitations. Learning the depths of what features are in each cloud provider. Account management is a beast. Identify the best way to structure for optimal velocity for teams and to have a secure pipeline to deliver software in.
  • Growing complexity in the cloud market has led to IT departments that have no idea how much they are spending on cloud workloads, or how their resources are being allocated. This lack of transparency has led to bloated budgets and can hinder developers who are seeking to deploy applications as efficiently as possible. To that end, we offer a very unique billing model that just like our products, is very simple. We only bill for core Compute and Storage products. We do not charge for every feature that we provide and offer hourly/monthly billing on all of our services. We also do not charge differently per region and provide a healthy bandwidth plan with very competitive overages. 

Here’s who we talked to:

cloud ,cloud obstacles ,cloud perception ,cloud security ,interview

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}