The path for transforming a business with Cloud-Native technologies is full of challenges. We need to discover how the business, processes, and applications will migrate to the new cloud landscape. Still, we also need to think about the cost for the team that performs and maintains that migration.

This is an aspect that is sometimes overlooked, and it deserves more attention, especially as the number of technologies and possibilities increases. Having a team that is and feels capable of maintaining this type of solution is key for the project’s success in the long term.

Up until now, the roles in a development team were pretty standard. Now, with the evolution of the technologies and development methodologies, those roles have started to fade into each other. If we consider the ideal prototype of cloud-native developers, they would need to:

• Understand the benefits (and challenges) of a microservice-oriented architecture.
• Be comfortable defining, creating, and managing container images.
• Be comfortable working with Kubernetes, which translates to understanding all the major entities (> 40) and are able to diagnose and solve common problems.
• Be familiar with the cloud provider being used in the organization.
• Be familiar with the specifics of using Kubernetes in that cloud provider.
• Last but not least, they understand the business challenge and are proficient in the target programming language.

This leads to a situation where adding a new member to the development team is as hard as finding a needle in a haystack. The Fullⁿ Stack developer needs to be proficient in a multi-dimensional space of technologies and applications. As roles were much more defined and bounded in the past, some of these tasks were 100% associated with DevOps/Systems. However, while the DevOps role is still expected to be the expert in the infrastructure side of the applications, developers need to extend their knowledge to be efficient in their day-to-day tasks. For example, testing/debugging a feature may require provisioning a new cluster.

The new bar is a risk in terms of available talent to extend our development teams and it directly impacts the qualified people who are already working within our organizations. In cases where enterprises are starting the migration to cloud solutions, these new requirements can easily overwhelm the existing teams, as the learning curve of some of those technologies in general, and of Kubernetes in particular, can be a daunting task.

Are we doomed?

New technologies are starting to focus not only on improving infrastructure usage but also on the users themselves. We at Napptive believe that the future of cloud-native applications starts from the app’s point of view and not from the infrastructure side. Infrastructure is becoming the new commodity, and the value of enterprise applications is derived from their functionality, not from the specifics of the cloud that they are deployed in.

With this in mind, we developed the Napptive platform to consider the application as the key element, and offer developers all the tools required to improve their experience by reducing complexity where it is not needed, with the added bonus that expert users can still access and tweak systems so that teams benefit transparently from those improvements.

What’s next?

As tools and products evolve in this category, some of the aspects that may change are:

• Provider agnostic tools: New abstraction layers such as the ones provided by the Open Application Model that enable us to specify what applications need, rather than how to get that functionality on a specific cloud provider (e.g., ingress)
• Simpler entities to interact with Kubernetes: To provide all the amazing features of Kubernetes, more than 40 entities are defined and used throughout the system for tasks ranging from defining a deployment, to setting the network’s policy. However, being able to understand how they interact among themselves requires passing through a steep learning curve. Tools that provide a set of top-level entities that facilitate the interaction with the system will make it more accessible for a large audience while maintaining the top-level functionality.
• Application-centric tools: Applications should be the new focus in terms of entities. By default, Kubernetes does not provide an entity requiring users to navigate and aggregate information from all individual entities manually.

We welcome you to use the Napptive Playground so you can experience how to deploy cloud-native apps within seconds. Think Heroku, but for complete applications and services.

Amongst the many benefits you will enjoy are:

• Improved developer experience with instant provisioning of virtual clusters. Easily share resources of a cluster using a managed namespace-as-a-service solution.
• Simplified application experience, write simple YAML files with support for parameters and extensions and avoid learning every low-level kubernetes’ entities.
• Application catalog to improve reusability; similar to docker hub, but oriented to complete applications, not just individual components.
• Application dashboard

It’s free to use, you simply need to log in with your existing GitHub account to get started!