3 ways to go from cloud-native developer to cloud-native architect

There can be many uncertainties as roles, titles, and responsibilities shift in the enterprise architecture space. The complement to that concern can be opportunity.

Here are three ways to think about the shift and turn it into a great career opportunity: To become a cloud-native architect.

#1 Embrace the business challenge

Regardless of the complexity and impact of the actual technology at hand, developers still need to deeply understand the business and workflow processes where the given technology will be used. Probably more than ever! In the digital era, "the application is the business," and "software is eating the world," right?

Once upon a time, IT was a cost center relegated to essential, but not necessarily appreciated, software systems. Well, applications no longer only support a fraction of business processes spread across various channels. The business is the software, and that's true whether you are a retailer or financial services firm. All companies must holistically manage their interactions with the customers from initial lead generation to post-sales services.

And that management need goes beyond your own domain. Customers barely interact directly with employees anymore. If the optimal marketing, sales, and support processes are improperly reflected in code, the customer loses faith, and competition is just one click away, ready to eat your lunch.

Thus, greater business-focused demand lands on the developers' shoulders these days, and those who embrace it—and its catchy vocabulary—can grow with it.

#2 Broaden your technical responsibilities

While cloud-native environments provide definite benefits for businesses, there are consequences for developers. First and foremost, developers have more responsibilities. Their microservices are packaged as container images, for which they must now define security, resource provisioning, performance, availability, and all the other -ilities of great developer experiences. Kubernetes has abstracted the burden of infrastructure management through APIs, but each organization has to tackle whether it's the developer's job to do that work.

What work is there to be done? Through YAML manifests describing their application artifacts ingested using the Kubernetes API server and additional sophisticated mechanisms such as operators, Horizontal Pod Autoscaler, the application's non-functional requirements are also under the direct responsibility of developers. Developers must specify locally a myriad of system parameters that were once managed at the enterprise level by infrastructure people.

The scope of responsibility that a developer has in this new paradigm can be quite broad. Not all developers will want this increase of responsibility, but those claiming it have a path to an architect title.

#3 Articulate the implications of cloud-native architecture

The team has adopted cloud-native, as described above. As we all know, Day 1 operations are a joy. What happens after that?

First, sustainability becomes essential: Will our dependent container base images be swiftly maintained with the latest releases? How? How will we get a hotfix into the DevOps pipeline? How do we securely package our container images? What are we defining as our sane defaults? Is it best to choose a minimal image and manually add needed third-party libraries, or will a "fat," "all-inclusive" image be better? Will any of this be sustainable if team members leave in the next one to three years?

Additionally, developers have to manage more third-party components than ever. The philosophy of cloud-native infrastructure as building blocks means every engineer must keep more context in mind than ever before.

Take Helm charts as an example. The sharing of charts makes Kubernetes more repeatable and customizable than ever. Helm charts allow developers to leverage the hard work done by the community and ISV to deliver code faster. The Artifact Hub lists over 2000 curated charts, but you cannot blindly install the useful Helm charts from the third-party repository. Even if published after thorough curation, those charts must be understood and customized before entering production for any user.

Additionally, we have to consider how those charts are correctly integrated into the existing DevOps cycle. For example, they must be scanned for vulnerabilities like any other internal artifact. In addition, their YAML manifests must be scrutinized and updated for weak configuration parameters.

Those external components increase the responsibility for developers. As a result, developers end up managing more code than ever before, even if produced by a third party and packaged in ready-to-use containers. Some organizations are starting Site Reliability Engineer (SRE) teams to carve off these additional code needs. SRE teams are, in many ways, a new form of IT architect to pursue.

The way forward

For the developer who embraces these modern distributed systems, the point is not to reject this evolution but to embrace the opportunity ahead. Aspiring cloud-native architects have to recognize this new context and find solutions to make it sustainable for their fellow developers.

Success does not come only from the technological choice of your operations platform. Neither Kubernetes nor any other technology is a solution in and of itself. Success originates in the proper connection between humans and software.

If you are a cloud-native developer willing to embrace these opportunities, you are sure to set yourself apart as the team's first cloud-native architect.