What's the most compelling investment a company can make when developing new apps on the cloud for the first time?

Abby Kearns

CEO at Cloud Foundry Foundation

Companies new to developing cloud native applications should first look at their organization. Do you have teams set up for success that can create, deploy and manage applications at scale in the cloud? Do you have teams that span functions and are able to work together to create a single product?

We often throw out terms like DevOps, Continuous Delivery, Agile, etc. But what companies really need is a way for their teams to get out new applications easily as well as the ability to iterate on those applications. The idea of writing cloud native applications is not just to move applications to the cloud, but instead to write smaller applications that you can quickly update as you, or your customers, need change.

These applications are often different from your typical applications. When we say cloud native, we really mean apps that are written to take advantage of the cloud: the ability to scale up (and down) quickly, as well as to be resilient in the event of infrastructure failures. Day 2 support of these applications is also key. You need to monitor and manage these applications in the cloud. Will that be done with your current Ops team, or a new "cloud-focused" Ops team?

Moving to a cloud native environment is not just a technical discussion, it's also a business one. Ultimately, the most compelling investment a company can make when developing new apps in the cloud for the first time is an investment in your developer team.

Jonathan Heiliger

Partner at Vertex Ventures US

The most important investment a company can make when developing apps on the cloud for the first time is deciding whether to natively embrace the cloud provider's interfaces and services or employ an abstraction layer. Neither solution is without trade-offs. Abstraction layers facilitate interoperability and independence from the underlying platforms, which enables (easier) migration to new cloud environments or solutions (particularly important for data storage). They can, however, come with an increased maintenance overhead.

A less obvious decision is how and where a developer should incorporate circuit breakers into the system architecture. Circuit breakers are of utmost importance in synchronous systems and ought to be a best practice in asynchronous systems that involve remote calls over a network, e.g. microservices architecture can be brittle because each user action invokes multiple services. When one or more services are unavailable or exhibiting high latency, it results in a cascading failure across the enterprise.

Service client retry logic only makes things worse for the service and can bring it down completely. There are multiple layers in a circuit breaker that can be implemented, (1) a literal switch in the code that detects network timeouts and prevents the call from running after a number of failures, (2) using feature flags, such as LaunchDarkly, developers can control the availability or refresh rates of specific features, e.g. delaying the refresh rate of an inventory call when database queues exceed a specified timer.

Sash Sunkara

VP, Products and BD at Kontain; Former CEO at RackWare

The most compelling investment a company can make and truly deliver value for their organization from the use of cloud is to architecturally shift to the use of microservices. Microservices and containers have transformed how complex applications are designed, developed, tested and run.

Companies can speed up the application development cycle that includes frequent code updates, new features and fixes. Development organizations can build, commit and test daily with smaller code units. This new way of developing can automate the delivery of high-quality code to production infrastructure in hours instead of weeks, delivering both top and bottom line benefits to businesses.

We are still in the early days of micorservices/container adoption for most software development organizations. The key to this shift right now is education. Educate yourself and your teams on what it means to build and operate truly cloud native software. Once trained, invest in architecting your software so it truly scales (from both performance and cost perspectives) the way world-class software ought to.

This doesn't just mean early training but continuous education, which includes dedicated time and resource allocation to keep up-to-date on the tools, trends and tricks, as well as a review of mistakes and successes others have been making. Setting a system where education is a part of life was always goodness, but in the cloud not having it is one of the most costly mistakes I see companies making.

Matt Murphy

Partner at Menlo Ventures

The first thing to consider in developing new apps on the cloud is to build a modular, flexible set of services (containers/Kubernetes/clean APIs) that allow rapid development of functionality, reduce points of failure, and increase opportunities for experimentation.

The most compelling investment to make to ensure success is to adopt a modern DevOps mindset and framework. Gaining a competitive advantage in today's environment requires that provisioning of infrastructure, rollout of applications, and updating of various services are rapid, frequent, predictable and secure! This DevOps stack that can deliver that should include tools for continuous delivery, feature flagging, cost optimization, app and systems monitoring, and incident management.

It's not entirely about DevOps, though. Building apps, as described above, combined with DevOps, enables the rest of the company to operate differently as well. It benefits product development disproportionately. More modular apps enable product teams to focus on smaller releases that can be implemented multiple times a day, with less risk, and on their own timeline (versus past methods of rolling out large, infrequent releases). This accelerates innovation, creativity and competitiveness.

In the DevOps stack, there are incumbent leaders in application monitoring, such as AppDynamics and New Relic. In systems monitoring it's Datadog, and in configuration management it's Puppet. In emergent categories: Harness leads in continuous delivery, LaunchDarkly leads feature flagging, and PagerDuty leads Incident Management, but a new set of players is emerging with more focus on SRE (systems reliability engineering) or increasing reliable uptime, such as Firehydrant and Blameless.

These new capabilities make it an exciting time in the world of app development. I look forward to seeing the continued benefits of these approaches and the innovation they accelerate.

David Linthicum

Chief Cloud Strategy Officer at Deloitte Consulting LLP

Clearly, the most compelling investment would be in the applications that have the most impact in the short term, less than a year.

This is different from enterprise-to-enterprise, but common cloud-based applications with the most immediate ROI would include: SaaS-based sales automation tools, highly connected supply chain management systems, and data analytics sitting on top of most of the enterprise data used for proactive business management as well as predictive analytics.

Tien Tzuo

CEO & Founder at Zuora; Former Chief Strategy Officer at Salesforce

Lots of companies don't get around to thinking about their pricing strategy until after they've spent a lot of time and resources developing their software applications. That's a mistake. Think about pricing structure first, then build with that in mind. In subscription models, we've found from our customer data that a combination of tiered and usage-based pricing works best. Our data shows that usage-based pricing boosts year-over-year upsells and reduces churn. The healthiest growth is observed in companies where usage is between 1% and 25% of subscription revenue.

So think about your basic platform features (bronze, silver, gold, etc.), then think about how to drive engagement with more elastic pay-as-you-go functionality.

Most video game apps, for example, make their money from superusers going crazy with in-app purchases. The key is to be able to offer choice but just the right amount that will spur growth. Too much flexibility can lead to unnecessary complexity, which can depress growth.