To gather insights for DZone's Cloud Research Guide, scheduled for release in April, 2016, we spoke to 28 executives, from 23 companies, who develop and deploy applications in the cloud for their own company or for their clients.
Here's who we talked to:
Neeraj Gupta, S.V.P. Product & Engineering, Apcera | Jad Naous, Product Lead, AppDynamics | Ez Natarajan, V.P. Head Cloud Services Business Unit, Beyondsoft | Alon Girmonsky, CEO and Founder, BlazeMeter | Kunal Bharati, Cloud Architect and Nishant Patel, CTO, Built.io | Sacha Labourey, CEO, Cloudbees | Deirdre Mahon, CMO and Fraser McKay, V.P. of Products, Cloud Cruiser | Flint Brenton, CEO, CollabNet | Ali Din, Senior V.P. and CMO and Walid Elemary, V.P. Product Development, dinCloud | Mike Masterson, Director of Strategic Business Development, Dynatrace | Gabe Monroy, CTO and Jasen Hansen, Chief Architect, Engine Yard | Fred Simon, Co-Founder and Chief Architect, JFrog | Jim Frey, V.P. of Products and Ian Pye, Co-Founder and Principal Engineer, Kentik | Johan den Haan, CTO, Mendix | Mounil Patel, V.P. Strategic Field Engagement, Mimecast | Faisal Memon, Product Manager, NGINX | Arvind Mehrotra, President and Global Business Head – Infrastructure Management Services, NIIT Technologies | Jens Eckels, Director, PaaS Business Group, Oracle | Pat Harper, SVP Operations, PGi | Joan Wrabetz, CTO, Quali | Partha Seetala, CTO, Robin Systems | Nick Kephart, Senior Director Product Marketing, ThousandEyes | Kiran Bondalapati, CTO and Co-Founder, ZeroStack.
When we asked these executives "What are the obstacles to the success of developing or deploying applications on the cloud?" here's what they told us:
- Scale is critical. You need to understand what scalability means and the many elements and moving points with regards to performance – availability, speed, and redundancy. Because everything is virtual, you don’t know what you’re getting when you rely on a third party to let you know the level of service you are receiving.
- What do backend services look like with Cassandra and Postgres? How to manage recovery. Getting parity between development and production environment – the lack of parity is still a big problem. A lot of moving pieces. Increase in the complexity is offset by the agility. Tools like Kubernetes help manage complexity of thousands to tens of thousands container images. There’s a trend toward micro services shifting complexity from the software to runtime. Runtime complexity demands a cluster-like tool. Need to select the right tool for the environment.
- Time to value is the biggest challenge. Automate everything to mimic every possible situation: pre-built model, automated build and tear-down, most complex with more customization, and automation is a requirement. Any big enterprise that’s bought a cloud management platform with self-service doesn’t have it up and running. It’s taking them more than a day or week so their lines of business will just go start one on Amazon in less than a minute. The situation today vRealizer, or some other product with no self-service doesn’t allow for rapid provisioning. You need to get deployed to see value. Provide enough value to be inside a private cloud than in a public cloud. The complexity of the physical infrastructure has increased. Private production cloud management platforms have not been successful. You can get a VM in a week. Customers are building cloud in a sandbox to test. Most customers need to mimic networks like telecommunications and mobile. Customers can’t migrate to Amazon they stay in their own lab. Go to private cloud of their own through their IT production department.
- People don’t understand cloud complexity, multi-tenancy, scalability. Mainstream enterprise IT hasn’t moved to the cloud. They’re shocked with multi-tenancy, and APIs. There’s a big learning curve. Ultimately they get to developer methodologies since they were previously unable to develop. Unlimited resources with no capex limitations.
- Problems are exacerbated for apps in the cloud. Communications of what’s talking to what when one service upgrades to another. Which client failed to talk to which server and why? Service-oriented architecture is taken to extremes in the cloud. Micro services in the cloud. One request to load the home page is combined with hundreds of other requests for other things.
- Customers are moving from speeds and feeds to the cloud where you can choose IaaS. Can do mapping to measure from the end-user perspective. There’s a big difference between the physical and cloud environment. Understand where you can impact change and control. How to accelerate apps using CDN network can deploy easily with servers around the world what does the data set look like. It’s a challenge moving data and servers to someone else. There’s a difference between utility and specialists who understand how to manage your needs. Now you have two people. No managed services provider but a team that’s helping in two areas.
- 1) There should be a standard methodology people follow to build and promote an app into production using Waterfall or Agile. The process of changing building tools necessary to make the changes, educate and comfort with the changes but a huge shift in human behavior is required. 2) Recruiting talent to do the work. Everyone is looking for developers. Developers are more interested in the development environment, fun, tools, what they’re learning, the challenges they get to tackle more than money. Be aware of what tools developers are using in college if you’re recruiting them. You need the right talent and skill. 3) The challenge isn’t deploying, it’s turning the apps on and getting them to go live from production. Enterprises don’t have a complete end-to-end process and visibility into each step to know what’s working and what isn’t.
- The old-fashioned issues of working with vendors and hard disks can’t scale in an automated way. It takes weeks and months to get servers up and running rather than minutes. Private clouds allow you to monitor your budget better than a public cloud. It’s a more effective cost point except for complimentary resources. There are significant economies of scale when you go private -- use cycles and data storage. We have more than a petabyte of storage. Changing the backend to use more SSD provides a huge jump in performance of the system. You couldn’t do this with AWS. It’s a more deterministic approach to get the performance you expect.
- Going from the generic “cloud” to the specific implementation therein. A lot of noise about time to value. The true value of cloud-based apps shortens the distance between the producer and the consumer for feedback analytics on usage – you know instantly if there’s a problem and you address it. This results in a short feedback loop for making improvements. It’s the same as DevOps with regards to a public cloud platform. DevOps footprint has made a staggering impact on the cost and time to delivery. We have the same number of developers as we have DevOps. It used to be 30:1. Much earlier emphasis on DevOps input and validation.
- 1) Lack of business logic and flexibility. 2) When building applications leaving security problems to someone else. You have to worry about security up front. The weakest link is the developer. Security has to be the first thing on a developer’s mind when building an app. 3) Vendor lock-in – you might start on AWS because they have so many services available but how do you know you’re using the best cloud solutions possible. Lock-in also restricts how you can build an app.
- Very few apps couldn’t be deployed in the cloud but it may not make sense economically. There’s philosophical resistance to change. Security at AWS and Microsoft is better than the enterprise.
- Skillset – people starting to think about how hard it is to find engineers that know the cloud world. Schools are not preparing students for the cloud though they are getting better. We have a good training program within our company. If you hire an engineer that’s not cloud savvy you be making the same mistakes that have already been made. A lot of software people are using things that are not made for the cloud. They’re made for the initial load but don’t scale. Have the technology maintain itself because the support’s not there – like Docker three years ago. If you want to be on the cutting edge, you have to be willing to take risks.
- The biggest is the ability to test apps without moving to the cloud to test applications, workflows, datasets, infrastructures, production scenarios. This can add weeks when migrating to the cloud. Predictive analytics of app behavior.
- Companies who don’t have the vision to integrate developers with all other business functions.
- For apps that already exist on premise, it may not make sense to move to the cloud. Need to evaluate the business needs and the costs. Be willing to let your app and data reside outside your hardware. I've spoken to lawyers that will never put anything in the cloud because they don’t want their app running on a cloud with another app that’s involved in illegal activity that gets shut down by the police or feds. A lot of people feel safer and more in control with apps and data on their servers even though AWS has invested far more in security.
- Lack of well-defined procedures and methodologies for design, development, deployment, operations, and support. Susceptible to scope creep. Customers are continually more demanding and the marketplace is more fluid. You need good leadership to get everyone focused on what’s most important. Have methodologies and approaches that will adapt to change.
- Legacy apps that were barely maintained don’t meet the native app requirement of the cloud. Investing in them is not useful. VM ware helps a little. Old apps are more or less generic. There are SaaS offerings like log analyzers, penetration detectors, and monitoring tools you don’t need to recreate, you’re better off just getting them as a service. Don’t evolve the app when there is already a service.
- Security, service encryption to prevent malicious attacks. Access control is different between consumer and enterprise apps though we see the evolution of consumer to enterprise (e.g. Dropbox). Start with a view of the target audience. Provide visibility and control.
- Network is moving to where the company no longer has direct control. Moved to IaaS or a co-location environment with business critical application service providers who want to know the health of their apps and troubleshoot issues to know where the problem is occurring or with which service provider. Payment gateways for financial services firms. Gaming companies with APIs from social networks. AWS is deploying with greater visibility and understanding and what actions to take. On the application side, there’s different rigorous testing for agile technology, microservices, distributed architecture can be difficult but important to test with rapid changes in the infrastructure and new micro services. We need services to solve the testing problems not adopted to IaaS and micro services. AWS is a set of services from foundational elements from EC2 with no testing to higher level like Lambda container and micro-services approach with a lot of built-in. Less in orchestration of service together. It is difficult putting all of the pieces together. How much will become vertically integrated?
- Challenges can come from either the company or vendor. Some enterprise applications have been so customized for on-premise systems and software that it's difficult to migrate them to the cloud. But legacy systems can sometimes pose a real challenge to companies looking at the cloud. Challenges can also come from a cloud vendor - especially those focused more on infrastructure-as-a-service. Sure you can put some of your deployment technologies in the cloud. But how are they managed? How are they updated and patched without down time? These challenges - among others - existed on premise and now they still exist for many apps living in the cloud.
What other obstacles to the success of developing or deploying cloud-based apps have you seen?