The emergence of “cloud native” technologies and practices, such as microservices, cloud computing, and DevOps, has enabled innovative organisations 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. Obviously 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” organisational 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 from software development enabled them to scale to a global phenomenon over the past two decades.
Obviously strong senior leadership and a willingness to continually change and adapt an organisation’s internal culture has had a large impact on the outcomes. One of the most important focuses has been continually working to sustainably minimise the lead time to delivering value. This can be seen by the drive to minimise the friction from having ideas, to coding, to releasing functionality, and to obtaining feedback. Organisations that have successfully embraced what we now refer to as a “cloud native” approach have invested heavily in two core areas: creating a self-service application platform, and adopting new tools and developer workflows.
From an organisational 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 organisation’s products and services, and leverage the platform and the new workflows to deliver value to customers.
Although beneficial, introducing these technical and organisational 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 specialised and often worked in silos. Operators built and managed data centers. Architects designed systems, 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. And 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.
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, the 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 popularised by Netflix.
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. 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 organisation by sustainably minimising the amount of friction and the corresponding lead time between ideas and delivering value to your customers. In order to fully reap the benefits of cloud native technologies, there are key organisational, 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 peak of the entire article series, you download the whitepaper “4 Essential Elements of Kubernetes Platform”.
Top comments (0)