{{announcement.body}}
{{announcement.title}}

Why Cloud Native? Speed, Stability, and Full Cycle Development

DZone 's Guide to

Why Cloud Native? Speed, Stability, and Full Cycle Development

“Cloud-native” technologies and practices have enabled innovative organizations to respond and adapt to market changes.

· Cloud Zone ·
Free Resource

The emergence of “cloud-native” technologies and practices, such as microservices, cloud computing, and DevOps, has enabled innovative organizations to respond and adapt to market changes more rapidly than their competitors. Just look at the success of the initial web “unicorns”, Spotify, Netflix, and Google. Not every company can be a unicorn, but there is much to learn from the early adopters of the cloud.

The Benefits of Being Cloud-Native

Spotify’s now-famous “squad, chapters, and guilds” organizational model ultimately led to the creation of their applications as independent microservices, which in turn supported the rapid rate of change they desired. Through a combination of a compelling vision and the whole-scale adoption of cloud services, Netflix was able to out-innovate existing market incumbents in the video streaming space. And Google’s approach to collaboration, automation, and solving ops problems using techniques inspired by software development enabled them to scale to a global phenomenon over the past two decades.

Strong senior leadership and a willingness to continually change and adapt an organization’s internal culture has had a large impact on the outcomes. One of the most important focuses has been continually working to sustainably minimize the lead time to delivering value. This can be seen by the drive to minimize the friction from having ideas to coding, releasing functionality, and obtaining feedback.

Organizations that have successfully embraced what we now refer to as a “cloud-native” approach has invested heavily in two core areas: creating a self-service application platform, and adopting new tools and developer workflows.

From an organizational perspective, these investments have broken down existing barriers between the operations and development teams that were traditionally mediated via ticketing systems. This has led to the creation of two high-level persona groups that collaborate via the use of well-defined APIs, automation, and focused in-person interaction:

  • Platform teams and site reliability engineers (SRE) own the platform, continually evolve the platform functionality, and help curate operational best practices; and
  • “Full cycle” development teams that own the organization’s products and services, and leverage the platform and the new workflows to deliver value to customers.

Although beneficial, introducing these technical and organizational changes has not always been pain-free. For better or worse, the traditional software development life cycle (SDLC) has been disrupted by the arrival of the cloud.

Full Cycle Development: Disrupting the SDLC

Within the traditional approach to the SDLC, engineers were specialized and often worked in silos. Operators built and managed data centers. Architects designed systems that drew boxes and arrows and provided architectural governance. Developers typically coded and tested a large batch of changes against locally running instances of their monolithic applications. 

Quality assurance (QA) engineers verified and promoted the systems using a series of gated staging environments. Applications that passed QA were handed-off to operations to deploy and run. After this, any issues or anomalous behavior was identified by the ops team and handed back to developers.

innovation

Agile enabled rapid innovation but didn’t fully break down the dev/ops barrier

Embracing cloud technologies, such as Kubernetes, has allowed the operations team to automate platform provisioning and developers to self-service in regards to application deployments. The use of microservices has allowed product-focused development teams to work independently. 

Accordingly, cloud-native SDLC is very different. Developers are performing just-enough upfront architecture design. Developers are coding small iterative changes against multiple services, some of which may be running locally, and others remotely. Developers are now seeking to automatically execute QA-style verification as part of the coding process. And developers also want to release rapid, controlled experiments into production. This approach is known as full-cycle development and has been popularized by Netflix.

full cycle development

Full-cycle development. “You build it, you run it” supported by platform tooling

It is worth taking a pause here to understand two core premises of this move towards “full cycle” development teams. This does not remove the need for specialist operations, sysadmin, or platform teams. This does, however, require upskilling within both development and operations teams.

Full-cycle development teams will have to cultivate an increased business domain expertise, and also extend their understanding of fundamental runtime configuration for their applications. The operations team will have to learn new cloud technologies and understand how these integrate with existing solutions into an effective platform.

Summary

As outlined here, embracing cloud-native technologies and development styles can provide major benefits for your organization by sustainably minimizing the amount of friction and the corresponding lead time between ideas and delivering value to your customers. To fully reap the benefits of cloud-native technologies, there are key organizational, cultural, and technical shifts that must be addressed.

I’ll be sharing more ideas on these topics over the coming weeks, and if you want to get a sneak peek of the entire article series, you download the whitepaper “4 Essential Elements of Kubernetes Platform”.

Topics:
cloud ,cloud native and kubernetes ,cloud native applications ,kubernetes ,platform approach for developers ,platform as a service

Published at DZone with permission of Daniel Bryant , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}