6 Strategy Elements for Building Cloud Native Applications

Mike Bilodeau

The cloud native paradigm for application development has come to consist of microservices architecture, containerized services, orchestration, and distributed management. Many companies are already on this journey, with varying degrees of success. To be successful in developing cloud native applications, it's important to craft and implement the right strategy. Let's examine a number of important elements that must be part of a viable cloud native development strategy. For a deeper dive into cloud native, check out our eBook Architecting the Future: Cloud Native Applications.

1. Prepare Well to Transition to Cloud Native

The first step in a successful transformation is to make a plan. Many organizations don't even get moving in the right direction because they begin with the technology. While new technology can be exciting, it can also be daunting. Otherwise highly beneficial technology can be misused to the point of frustration and abandonment.

At the outset, it's critical to involve your leadership, partners, and customers. Present your findings and high-level plans. Assemble the right team and work together to divide your cloud native journey into phases. Then, break these phases into development projects, sprints, and actions. Set clear expectations and frequently collect feedback.

Resist the temptation to pursue the technology before you align your business mission, vision, and people with your cloud native aspirations.

2. Transition Away from Silos to DevOps

Despite the prevalence of agile methodology, application development is still commonly organized into these silos:

Software development
Quality assurance and testing
Database administration
IT operations
Project management
System administration
Release management

This arrangement enables specialization for managing staff who perform the work in each area. Typically, these silos have different management structure, tools, methods of communication, vocabulary, and incentives. These differences correspond to disparate views regarding the mission and implementation of the application development effort.

DevOps is a both a methodology and an organizational structure. It aims to break silos open and build a common vocabulary, shared toolsets, and broader channels of communication. The goal is to cultivate a culture that intensely focuses on frequent releases of high-quality deliverables. DevOps replace heavy procedures and unnecessary bureaucracy with autonomy and accountability.

3. Move from Waterscrumfall to Continuous Delivery

Today, many agile teams find themselves immersed in what Dave West calls the waterscrumfall. Yes, it's good to embrace Agile principles. Too often, however, the organization does not. On many agile teams, the result of each iteration is not actually a production-grade deliverable. Incidentally, this is the original intent of the Agile Manifesto principle of working software.

What is more common is that the new code is merely a batch that gathers together with other batches downstream. This closely resembles the conventional waterfall model. This apparent reversion to conventional development actually diminishes two key benefits of agile delivery. Firstly, customers go several weeks without seeing any addition to the value of the application under development. Secondly, the development team endures the same period of time without receiving any truly valuable feedback.

To develop cloud native apps and realize the benefits of cloud-native architectures, it's necessary to make complete a shift to continuous delivery. In CD, application changes are deployed automatically—several times a day. Some teams are having much success, but only because they have built product development pipelines that automate code integration and testing. A mature, productive CD pipeline leaves the team with only one decision to make at the end of the day: Does it make good business sense to deploy the application with all of the new changes?

Let's now turn to the implementation issues that are necessary in making the move to cloud native application development.

4. Decompose Your Monolith

Conventional multi-tier monolithic applications are rarely found to function properly if they are moved into the cloud. This is because such a move is usually made with several major, unsupportable assumptions about the deployment environment. Another inhibitor is that a monolith deployment is closely bound to a static, enduring infrastructure. You're probably thinking—quite rightly— that this is largely incompatible with putative cloud-computing expectations for an ephemeral and elastic infrastructure. Since cloud infrastructure doesn't provide good support for monoliths, it's necessary to make a plan for breaking a monolithic application into components that can live happily in the cloud.

5. Design a Collection of Services

In essence, a cloud native architecture is commonly seen to be a service-based architecture. Optimally, cloud native applications should be deployed as a collection of cloud services or APIs. However, while the concepts are readily understood, many developers still have a strong tendency to create tightly-coupled applications. Such apps align and bind tightly with the user interface. To leverage cloud-computing assets and benefits effectively, a cloud native application should expose supporting functions as services that are independently accessible.

When developing an application architecture for the cloud, it must be built to interact with complex, disparate, widely distributed systems. These systems can support multiple loosely-coupled applications. Such apps are built to employ many services, and also remain decoupled from the data. Developers can build up from the data and use it in communicating with services. These services can be combined into composite services—and composite applications—that remain flexible and scalable.

6. Decouple and Decompose the Data

It's not enough to simply decompose monolithic applications into microservices. In addition, it's also essential to decouple the data model. If a development team is given the freedom to be "autonomous", yet must still contend with a single database, the monolithic barrier to innovation remains unmoved.

If the data has been tightly bound to an application, it can't find a good home in the cloud. Think about it: it's necessary to decouple the data for the same reasons we know it's best to decompose application functions into services. The effort to decouple the data will be richly rewarded with the ability to store and process the data on any cloud instance.

Conclusion

Cloud native application development does require that you invest in a new way of thinking and some new development paradigms. However, many conventional concepts remain important, including good design and automated testing. A key takeaway is that a service architecture should be given priority, even if it will initially result in a lengthier app development lifecycle. Even if part of the cost is a temporary increase in budget, the long-term gains in efficient will perhaps make it the smartest investment your team will ever pursue.