Additional Considerations — Cloud-Based Apps

DZone 's Guide to

Additional Considerations — Cloud-Based Apps

Two keys: 1) Not all cloud providers are the same; 2) containers provide portability; and, much more...

· Cloud Zone ·
Free Resource

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 have I failed to ask you that you think we need to consider with regards to developing and deploying applications on the cloud?" here's what they told us: 

  • We’ve covered the key challenges of scale, transparency of information, challenging the engineers to address these topics. Not every cloud vendor is the same, they are not commodity vendors. Each one is unique and opaque so it’s tough to source and evaluate. We provide benchmarking tools for various cloud vendors to benchmark and see what to expect based on past experience. We provide immediate access to all cloud vendors.
  • The most important question for the industry to ask is why do we want to adopt? What do we get in return? A lot of simplicity. Reasons to move to distributed systems is trendy, a lot of companies may not need to move. Understand the tradeoffs. Run your infrastructure like Google runs theirs if you have the scale—there are a lot of benefits even is you just have 20 servers.
  • Containers. If you containerize they’ll be: 1) portable–that’s what they do best; 2) able to move from cloud to cloud; and, 3) be cloud agnostic so it’s able to work in all types of clouds.
  • How can big companies help small companies to make development simpler? How can big companies collaborate with small? Big companies have the ability to empower small. Everyone benefits with open collaboration. Linux started this way and people at large and small companies are writing around it. The biggest hurdle for the developers is the inability to share ideas. They’re told to go to their bench and build, build, build without taking time to share what they’re building or explore their ideas.
  • Know where the budget will come from. Developers are more in control but they have not been responsible for the budget in the past. Be aware that you can provision what you need but that you’re also responsible for a bug or a tremendous increase in scale. You’ll be asked to help predict the budget, the number of users of the app and the cost. If you don’t have the sufficient budget in place it could bring the app down. Great services are cloud hosted but be careful with the security policy. There was a GitHub incident where someone checked in and someone else had gotten access to their apps which were no longer in a sandbox. Have the right controls in place. Know the rules of engagement. Understand that you're accessing APIs, code checking in a somewhat public network. Know what’s secure and what isn’t and where the potential security risks are. This brings security into application development much earlier. Architect in security principles from the beginning.
  • The world as we know it is built around cloud-based applications. No one could predict where we are today five years ago and no one can predict where we will be five years from now. Commit to lifelong learning and you’ll always be able to use what you learn.
  • They've gotcha with a private cloud—be very careful committing to a private cloud. We have a good relationship with hardware vendors. We’re always testing.
  • People talk about cloud apps but 90% of apps are still legacy enterprise apps. How can we take these apps and deploy in the cloud? We allow you to do this with containers or operating systems.
  • The main thing is to ask why you are developing the app and why it should be cloud-based. If you can’t answer those questions, you will not build the right solution. Why do we need a cloud model? Who is the right provider–public, private, or hybrid? Write down the answers to the questions so everyone on the team knows the answers and you can refer back to them. Make sure you know how the cloud app is supposed to look and consider open source technology that may help you build it. Design how first. Doing a blueprint without a provider is also helpful–there will be no preconceived notions or restrictions.
  • There’s a new way of doing things. It used to be cloud engineers. Now we have developers working with DevOps for scalability, backup, restore, and security. Get the job done, create APIs and discuss with the team. App monitoring fault tolerance of everything in the stack across all components and services. DevOps handles security and penetration tests. Everyone needs to be thinking about how to deploy in a secure environment. One team with separate skill sets.
  • Re-architecting from a microservices standpoint helps move apps, manage, provides more connectivity to more places. If you re-architect for microservices, you don’t have to do as much. Must segment correctly. How to get ACID into the game. Migration is a highly critical factor.
  • Developers will still need to program and collaborate. The entire team moves to a collaboration orientation.
  • The future of development and deployment is: internet as a service, platform as a service, and software as a service. A good developer will understand all three.
  • Test for failure. This is one of the models of Netflix. If anything fails in my system, then we need to bring down the service so we don’t put our, or the customers’, data at risk. Plan for failure. For the last two years, cloud service use has increased and enabled users to skip a lot of processes. Don’t give up on a testing your system for failure. This is part of the open source tools provided by Netflix. It’s better for you to find the problems in the app yourself than an intruder.
  • A lot of companies fail to see the soft cost when considering cloud for their apps. If a cloud vendor doesn't offer pre-integrated services and easy management across the technology stack, you'll end up with a hodge-podge of tools and management methods that can eliminate the cost savings of cloud relatively quickly. Rather, companies should look at vendors who provide easy, continuous integration/delivery environments, rapid spin-up and tear-down for testing, transparent updates of infrastructure and so forth. Buying space on a cloud server may seem to be a cost savings - and it is. But if you stop there, the true power of cloud could go unrealized.

Anything we've missed in our series on developing and deploying cloud-based applications? We'd love to continue the discussion and get your point of view.

application security, cloud-based applications, private cloud, public cloud

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}