Armon Dadgar

CTO and co-founder at HashiCorp

Flexibility and freedom in an app’s initial development can come at the cost of Day Two operational efficiency. Things like security and compliance become especially challenging when less standardization is introduced upfront.

With cloud-native, less is often more. Companies benefit from standardizing on a few services governed by a central platform team rather than a wide array of services adopted ad hoc by application teams.

I’ve spent the last few months traveling and meeting with customers from Houston to Singapore. I’ve consistently heard about these challenges and seen firsthand how companies seeing success in the cloud are creating centralized platform teams to control costs and enforce consistent security policies. These platform teams reflect how important standardization is for cloud infrastructure at large companies. In the early days of cloud adoption, individual teams used disparate tools to meet their needs, but now that the cloud is the de facto standard, CIOs are standardizing their approach to infrastructure so that there is one team — and one budget center.

Many organizations may struggle with this trade-off, but it’s the right one. Especially when facing the growing skills shortage to build and continue to run cloud and multicloud infrastructures.

Day One is temporary; Day Two lasts forever.

Dana Lawson

Senior vice president of Engineering at Netlify

The biggest challenge companies face when producing cloud-native applications is taking the old rituals and practices that were applied to non-cloud native development (CI/CD, local development and production promotion, etc.) and trying to apply them to this new style of development in the exact same way. This takes away from some of the benefits of cloud-native development, including speed of execution and consistency no matter where an application runs in public, private or hybrid cloud situations.

Peter McKay

CEO at Snyk

The hardest thing for companies to get right with cloud-native application development is the organizational shift required across Dev, IT, Ops and Security teams. In the pre-cloud world, IT and Ops had a centralized and controlled role in how apps were developed, secured and run. With cloud-native applications, the scope of responsibilities has shifted to developers, DevOps teams and today, product security (SecOps). Application security has become decentralized as vulnerabilities exist across the entire SLDC and continuously in open-source libraries, containers, cloud infrastructure and proprietary code. This has created an increased need for Development, Security and Ops teams to work together to secure the entire cloud-native stack from code to cloud and back into code.

For example, recently disclosed vulnerabilities within code and applications — most notably Log4Shell in December — shed light on the significant security challenges applicable to cloud-native application development. Because cloud-native applications are so crucial to businesses today, organizations from the largest banks in the world to the most viral consumer app utilize open-source and cloud-native technologies to deploy innovative features fast and continuously to meet consumer demand and revenue goals. If organizations are set up for the pre-cloud world, it becomes nearly impossible to develop fast and stay secure as traditional security methods break down and are in constant conflict with business objectives. The best ways to address these issues is to embed security across the entire cloud-native application development lifecycle, within a developer’s workflow, and encourage a new cloud-native mindset bringing together Security, Ops and developers as one team.

Kenny Johnston

Senior director of Product Management at GitLab

One of the single most valuable — and challenging — things for an engineering organization to achieve is speed. Today, every business is a software business, whether it realizes it or not. Any organization not making the right software investments is threatened by a competitor that is. At the heart of achieving speed are developers. Developers are under immense pressure to deliver competitive product features, maintain application availability and bolster security — without sacrificing speed.

Cloud-native architectures are designed to create resilient services that are orchestratable and self-healing, but cloud-native development alone is insufficient. The single proven method for achieving modern business speed is the use of one DevOps platform that fully confronts cultural and collaboration challenges in software delivery.
To overcome cloud-native development roadblocks and drive DevOps-based transformation, organizations must focus on:

• Organizational alignment: From the C-suite to developers, organizations must unite everyone in the software delivery process to shift away from legacy systems while embracing new technologies that accelerate software delivery.
• Cultural change: Break down silos between decision-makers, development, operations and security teams to create a single source of truth with real-time, centralized communication and collaboration.
• Collaboration platforms: Ditch DIY DevOps systems that prevent simplified, repeatable processes and move to a single-platform approach that enables the organization to deliver software faster, more securely, at scale and with cost efficiency.

Mike Tria

Head of Engineering at Atlassian

Building cloud-native apps in a “you build it, you run it” (YBIYRI) world is by far the most challenging part of modern engineering. Cloud-native means a developer is also a DevOps engineer, a database administrator and a network engineer all rolled into one. Sure, the hardware concerns go away, but the contextual load on an engineer goes up quite a bit.

Our recent State of Developer survey research shows almost 60% of developers now work in YBIYRI environments, with a larger number (over 65%) agreeing that they should be responsible for more of the software product life cycle than they currently are. Developers who are close to a product or service have the potential to improve it further when given a high degree of ownership.

Luckily, the tooling and support for a cloud-native engineer has never been better. Engineering leaders can lighten the load on developers by creating more space for development teams to take on YBIYRI responsibilities, ensuring they have the right tools, processes and rituals to be successful, which will mean faster development times for cloud-native apps.

Reza Shafii

VP of Product at Kong

One thing companies often underestimate is the highly automated and dynamic nature of an application’s environment in a cloud-native world.

Application updates are typically performed dozens (if not hundreds) of times a day, thanks to DevOps automation. Each component of your application, whether implemented as a microservice or not, can be dynamically scaled in/out or be moved around.
This means that the journey to cloud-native is not a simple lift-and-shift of your existing application architecture or development processes. Both aspects need to be reconsidered to accommodate the new dynamics. Applications that don't take this into account do miserably in cloud-native environments, while applications that are built with these properties in mind from the start excel.

In other words, if an application wasn’t built with cloud-native concerns in mind, deploying it in a cloud-native infrastructure or environment is like going into battle on a cruise ship. A cruise ship that’s large, inflexible, slow and incapable of adapting.

Priyanka Sharma

Executive director at the Cloud Native Computing Foundation

The most challenging thing for companies is finding a balanced framework that ensures a certain level of service is provided and also allows for experimentation and testing of new approaches. To get cloud native development right we must figure out the proper abstractions for our infrastructure, applications, and architectures. What makes sense for us to measure or observe? What standards and interfaces make sense for our projects? Often, the trap that teams can fall into is prioritizing a tool or specific practice above the implementation itself, which leads to churn and can hurt adoption. Making sure to focus on our workflow and the connection points between our workflows helps with adoption and acts as a feedback loop to confirm we’re making the right choices.

Essential to rising to the challenge of cloud native is having a culture of psychological safety. Our teams need to feel comfortable learning. If mistakes can be transformed into a lesson learned or a process improved, the entire organization can profit from an accident or error. With the increasing number of new practices that arise each week (let alone each month, quarter, or year), generating hypotheses and testing those is the only way we can validate our approaches.

For both, finding a balanced framework that allows for experimentation and maintains a level of SLOs and for building a culture of safety, I highly recommend investing in a top tier developer experience team that can build the guardrails and policies for the organization.

Danny Fields

Chief technology officer at Avalara

The biggest challenge about getting cloud-native application development right is reliability. People often think that when you move into a cloud-native environment, your application will be extremely reliable, and most public cloud vendors say that they’re always on and don’t have outages. But most developers build an application to work really well on only one server and one computer, and forget that sometimes a service can die. It’s critical to remember to design applications to withstand any kind of cloud outage.

Cloud providers have data centers made of millions of machines and servers. Sometimes, some of these servers will fail, and if applications are built to only run on a single server, then a company faces outages, which are both costly and time-consuming. Companies must design their applications so that they work across multiple servers and multiple data centers to ensure ongoing high availability of services. The best way to do this is to design reliability into applications from the beginning, as the benefit of the initial investment far outweighs any alternative.

Simonetta Turek

GM of Customer Experience Products at Twilio

Recruitment and retention of technical talent that will help you build for the long term is the single hardest thing for companies to get right about cloud-native application development, but it’s also the single most important thing.

Today, it’s possible to build an application for your needs quickly: But remember, it’s a marathon and not a sprint. Stick to strong architectural principles and practice operational agility to avoid creating legacy debt before the product has traction in the market. And this must all be backed up by the best talent you can find. To note, the race for technical talent is only set to intensify, with the demand for software developers estimated to increase to 22% between 2022 and 2030. Finding and retaining the right technical talent that can continuously innovate and leverage these technologies is hard to find, but will pay dividends in the end to build native cloud applications that will succeed, adapt and solve customers’ problems.

Jim Walker

Principal product evangelist at Cockroach Labs

A “single” hardest thing is a bit difficult to define as we see many organizations maturing through their cloud-native journey at different paces. However, the companies that get it right understand it’s not just about an evolution of what we used to build, but also how we work and think about our applications. Often, companies confuse using cloud-native tools with being cloud-native, but there are a few patterns that some of the more mature organizations demonstrate. First, the concept of location matters. Understanding the physical nature of your infrastructure, data and services is incredibly important. Which leads to the second point: The incorporation of a “distributed mindset” is core to becoming cloud-native, as this is not just a technology evolution, but also a mindset and paradigm shift. Distributed systems are inherently complex, and need a different approach — they shouldn’t be addressed in the linear approach of the past. Those that are embracing this cloud-native approach are pushing this distributed mindsets up the stack from infrastructure up through the database and into their applications. This level of maturity is rare but super powerful.