What does it take to build a cloud-native app? The conventional answer (which is exemplified by the CNCF's official cloud-native definition) is that cloud-native is all about using containers, microservices, service meshes and similar technologies to build apps that are scalable and composed of loosely coupled components.
But there's another element of cloud-native development that often gets left out of the picture. Cloud-native applications are also composed of pre-built components and services. The ability to take chunks of code that were written and neatly packaged by someone else – like open-source container images and a service mesh that makes it easy for them to talk to each other – and use them to build a complex application quickly, is part of what makes the cloud-native approach so powerful.
That said, succeeding as a developer in the cloud-native age requires more than just bundling together a bunch of application components created by someone else. Developers must also be able to add unique functionality to their apps. Otherwise, what they create isn’t anything special, or is something that another development team could have tossed together with minimal effort.
Here's why focusing on unique functionality is key to success in cloud-native development, and what that focus means in practice.
The cloud-native developer's conundrum
Developers in the cloud-native era face a kind of inherent tension. On one hand, they are expected to create apps quickly using preconfigured and prebuilt components. On the other hand, they're told that it's important for their apps to do things that the competition's applications can't. Otherwise, they risk failing to "delight" their users.
To put this in more concrete terms, consider how you'd go about developing a simple microservices app that has three components: A frontend that hosts the application interface, authentication service, and a database backend.
In previous eras, developers would have written the code for each of these components separately. Today, however, probably only the frontend would require a lot of original coding. The authentication service could be implemented quickly by taking a prebuilt container image for a tool like OAuth and doing some tweaking. Similarly, the backend could be based on a container for MySQL, MongoDB or whatever the team wanted to use.
The ability to create complex apps quickly by leveraging prebuilt components is part of what makes cloud-native development so great. Developers can deliver apps in weeks that previously would have taken months to write. What's more, cloud-native apps are easier to maintain because they are composed of reusable chunks of code; unique codebases are few and far between.
But the downside is that an app that is created using prebuilt, widely-available components (like OAuth or MySQL container images) is not a very original app. There are probably tens of thousands of apps out in the world that run on the same code.
That's why, in terms of both user experience and performance, there is little to distinguish typical cloud-native apps from one another. Most end up being more or less the same.
Adding unique functionality to cloud-native apps
How can developers address this issue and make their apps unique?
Their first instinct might be to write more original code or spend more time customizing the prebuilt components they get from upstream. But if they do that, you partially defeat the purpose of going cloud-native in the first place. You end up with a development process (and a resulting application) that is not scalable.
A better approach is to look for pre-built application components that allow teams to implement unique functionality. Instead of drawing from the top 100 container images in Docker Hub, they can turn to a marketplace of cloud services that let them implement features to make their app more unique or that offer better performance than the ones they can find in public repositories.
And, because the services in the marketplace are also pre-built, they don't require major additional coding or configuration to use. Thus, developers get the best of both worlds: unique functionality and ease-of-implementation.
As a bonus, the services inside a developer marketplace tend to be compatible with each other, so developers need not worry about writing extensive custom code to build integrations. This is not always the case when it comes to other cloud-native building blocks; open-source container images don't typically integrate automatically with each other, for example.
This isn't to say developers can't still use container images or similar pre-built components. Those resources might be used to form the foundation for an app. But after that foundation has been set, development teams can turn to marketplaces to build out their app and add more unique functionality.
Developers want the ease and scalability of cloud-native development patterns. But they also want to build apps that stand out from the crowd. Conventional cloud-native development techniques aren't always enough for that purpose. But when they have access to a marketplace of cloud services, developers can choose from a more extensive and more original menu of features to add to their apps. Their apps are better, developers have more fun creating them and end-users get a better experience.
<div class="blog-cta"><h3 class="blog-cta-headline">Sell APIs to developers in our network of cloud platforms.</h3><a class="button button-brand" href="/providers"><div class="button-text">Get started</div><img src="//assets.website-files.com/5d5acff74a2e86484bb721fc/5d7bbab3af998bd22c394550_arrow_right.svg" alt="" class="icon"></a></div>