Successful cloud native adoption requires the identification of key principles that can guide the implementation and operation of cloud native systems.
These principles - we see six of them - serve as a foundation for decision-making and help teams align their efforts towards common goals.
1. Embracing the Essence of Cloud Native Thinking
Establish a common understanding of what cloud native is and why you are using it. To understand the heart of cloud native thinking, start with the software engineering concepts described in the 12-factor app. This inspired a cloud native open-source revolution, as well as the founding for the Cloud Native Computing Foundation. Start from here and keep it simple.
Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.
The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.
Another place to seek alignment is through DevOps principles and practices. Most of you already have this going on in your organization, but these books are a great path for alignment on the DevOps way.
Furthermore, I must mention the IEEE 2675-2021 DevOps standard publication. I am excited to share that I have recently become a member of the IEEE DevOps working group responsible for updating and enhancing this standard.
It is important to note that while the DevOps movement encourages "shift-left" practices to empower developers and promote innovation, it can also lead to increased cognitive load and potential burnout.
This phenomenon, known as "ghostOps," occurs when key technical resources leave behind a messy situation while chasing the next shiny object. Many of organizations have experienced this. However, Team Topologies can help address these challenges by establishing clear boundaries and responsibilities between application delivery and platform teams. This allows for a more streamlined and efficient workflow.
2. Automate! Application and Infrastructure Deployments
One mantra we hear a lot about is, "automate everything". It is a core DevOps practice that should be top-of-mind every day, all day. It is essential to reduce toil, cognitive load and ultimately burnout.
Automation has come a long way in the last 10 years. We've seen a shift from scripts (an imperative model) to Kubernetes and infrastructure as code (declarative model). In the declarative model we specify the desired state of an application deployments or infrastructure resources as configuration, then we let the tooling "make it so". No longer do we have to know the sequential steps of how these resources go from their current state to the desired state. This is huge!
Two toolsets that have driven cloud native DevOps success, enabling declarative models are IaC tools and Kubernetes. We use infrastructure as code and deployment manifests, semantically versioned with modern source code control systems to abstract away the complexities and particularly dependency management.
This new class of tooling is very powerful in the context of Team Topologies, as it allows us to divide assets between the application delivery (stream-aligned) teams and the platform teams (possibly the complex algorithm teams, as well) in a clean API contract way. For instance, the platform team may create Terraform modules for the app teams to use for deploying their database of choice.
3. Put Conway's Law to Work with Intentional Architecture
We often overlook the potential benefits of applying the same principles of loosely coupled architectures to our infrastructure and cloud designs. However, Conway's Law teaches us that there is value in mirroring the social organization of our teams within our cloud infrastructure. By intentionally designing our cloud architecture to align with our team topologies, we can create a more cohesive and efficient flow across our organizations.
In practical terms, we can leverage two powerful patterns in our cloud native environments. The first pattern is the hub and spoke architecture, while the second is the Cloud Adoption Framework Landing Zone. By combining these patterns, we create a structure that allows for innovation and autonomy in the spokes of the landing zone, while the hub provides centralized management and guardrails.
This architectural approach has a significant impact on the organization of accounts, subscriptions, VPCs, and VNETs, creating atomic and independent spokes for application delivery team environments. As a result, network traffic flow, cost management, and IAM become more natural and seamless.
4. Putting Cloud Native Culture into Action
Embark on an exciting cloud native adventure as a united force. Nurture an environment where the brilliant minds of your organization's cloud native experts feel like they are part of a cohesive movement, rather than separate and competitive teams.
This approach will facilitate the transition towards a generative culture, nurturing a safe learning environment for the front-line technology teams.
These teams thrive by actively building, deploying, and supporting real software systems. Keep in mind, some risks may need to be taken to achieve success. Embrace the true spirit of improvement by celebrating experiments, regardless of their outcome. The objective is to learn and move forward. This cultural foundation sets the stage for your platform team.
As these talented individuals come together across different teams, they can be brought into a dedicated platform team whose ultimate objective is to empower application delivery teams by alleviating the cognitive load and learning curve associated with cloud native platforms. This platform team strives to provide highly curated and code-ready platforms as a service to their software engineer customers.
5. Collaborate, Facilitate, and Publish
A key lesson that we consistently learn is the importance of identifying, building, and maintaining platform team services in a strategic manner, and Team Topologies can greatly assist with this process.
When developing a new platform service, it is crucial for the platform team to collaborate not only with enablement teams like enterprise architecture but also with the application delivery team that requires the service to release a product feature. It is vital to avoid the platform team working independently and building something without direct collaboration with the application-delivery team.
Speculative ventures should be avoided, and platform teams must always prioritize supporting the feature velocity and requirements of an actual delivery team while the product features are being built.
A proven strategy that has yielded great results is to start by collaborating with the application delivery team to deliver the thinnest viable product (TVP) of initial an service. This approach has proven to be highly successful in guaranteeing a smooth implementation and expediting the critical path for the application delivery team. Expect some refactoring and thoroughly documenting of the service assets before delivery to the subsequent application delivery team.
Finally, as the platform service assets become more refined and documented through further deployments, the team may decide it mature enough to publish it as a self service asset. Both the facilitate and publish stages may increase their benefit from the features of an internal developer portal (IDP), such as Backstage.
6. Consider a Digital Foundations Jump Start
At nvisia, we have had the privilege of working with some great clients, helping them to adopt cloud native practices into their platform teams. In doing so we have seen some powerful patterns emerge! Following the DevOps path of "automating everything", we have captured these proven patterns for hub and spoke with CAF landing zones on AWS and Azure as nvisia Digital Foundations.
Our team of DevOps and Platform Engineers facilitates a 3-week discovery and design phase to configure the hub and spoke architecture. From there, we collaborate with our clients to deploy the DF Terraform modules with Azure DevOps pipelines to create code-ready microservice landing zones. Usually, teams are deploying their first microservices to their Kubernetes + Istio powered landing zone in about 4 weeks! Oh, and you have full rights to use all of the code that we bring, forever, without any additional licensing - it's yours to use and evolve.
By identifying and embracing these key principles, teams can move toward a successful cloud native adoption journey.
Learn more about nvisia's Cloud Native Digital Foundations capability and Team Topologies.