Cloud native has become one of the biggest trends in the software industry. It has already changed the way we think about developing, deploying and operating software products. The cloud-native paradigm for application development has come to consist of microservices architecture, containerized services, orchestration and distributed management.
Organizations across every industry want to remain competitive, and there is a strong sense of urgency to adapt quickly, or become irrelevant. The pressing need is to secure the right amount of infrastructure flexibility and performance elasticity to manage unpredictable usage volume and geographic dispersion. Many companies are already on this journey, with varying degrees of success.
RELTED CONTENT:
Understanding the meaning of cloud-native apps and development
Big bang theory? Not for cloud-native development
A recent Cloud Foundry survey of approximately 600 IT decision makers revealed more than 75 percent are evaluating or using Platforms-as-a-Service (PaaS), whereas 72 percent are evaluating or using containers. Nearly half (46 percent) are evaluating or using serverless computing. Notably, more than one-third are employing some combination of all these technologies, and it’s in those companies using all three technologies that cloud-native computing is gaining momentum.
Adopting cloud-native architecture is much more than merely moving some workload over to a public cloud vendor. It is an entirely new and different approach to building infrastructure, developing applications and structuring your teams. Below are six steps enterprises must take to ensure a successful transition.
1. Plan to transition to cloud native
The first step in a successful transformation is to make a plan. Many organizations don’t move 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. Ultimately, both the leadership and the engineering team must be aligned on both the business goals and the key results that the organization hopes to achieve in the short and long term by initiating a transition. Without this mutual understanding, the engineering team risks to prematurely optimize the architecture for use-cases that are irrelevant to the business.
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 the following silos: software development, quality assurance and testing, database administration, IT operations, project management, system administration, and release management.
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 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 (CD). In CD, application changes are deployed automatically—several times a day.
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. 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. 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.
Moving to a cloud-native architecture will include time-consuming challenges requiring diligence and dedication. It’s not simply getting apps to run in a cloud-computing environment. Cloud native demands major changes in the supporting infrastructure and a shift to designing apps around microservices. In addition, foundational change requires new tools for cloud-native operations.
But the long-term gains will be extraordinary. Enterprises can go from idea to app in the shortest amount of time. No other app development paradigm is more efficient. This is one of the smartest investments an enterprise can pursue.
To learn more about containerized infrastructure and cloud native technologies, consider coming to KubeCon + CloudNativeCon San Diego, Nov. 18-21.
