This is a post ported from https://medium.com/@lachlan_white
One of the biggest challenges that enterprises face as they migrate to cloud is transitioning from a traditional services based IT operating model to a cloud native self-service model.
Whilst attempting to explain this problem to enterprise architects and management, it dawned on me that I had never seen a visualisation of this. Immediately I thought of the shared responsibility model and how cloud providers have used this to demonstrate the value of moving from On-Premises to SaaS services.
Below we have Microsoft’s shared responsibility model, which shows where responsibilities on each hosting platform lie for each party (Cloud Customer or Cloud Provider).
Credit: Microsoft Design
Translating this to my model I landed on the below visualisation. Starting from the left in the land of Traditional IT, responsibilities are clear. The App Team looks after the application layer, the Infrastructure Team has all of the infrastructure components and the Data Team has the data, etc.
This Traditional IT model has worked for decades in a way that mitigates risk to our running services and allocated responsibilities clearly to individual teams. It was born out of ITIL and On-Premises based technology solutions. As a result of this, if we attempt to apply this Traditional IT model to Cloud-based technologies we run into many issues, mainly around:
- High Barrier to Entry
- Cost to Change
- Scaling Limitations
- Closed to Innovation
So as an attempted fix to this, organisations will often establish a fledgling DevOps capability. However, the mistake that is typically made is one of implementing a DevOps Team, rather than adopting a DevOps Culture.
Credit: J. Michael McGarr
When a DevOps team is implemented you can see they look to take on capabilities across everything from storage to applications. Because we are working in a Hybrid IT world, with both Cloud and On-Premises technologies this leads to issues, such as:
- Large Overlaps of Capability
- Battles for Control
- Cross-Team Communication Barriers
- Deep Coupling
It is these ‘Battles for Control’, that cause the largest impacts to culture, delivery and overall morale of teams in a Hybrid IT world.
Battles for Control are the death of any benefits gained from a Hybrid IT Model. When there is no strategic enablement, it is left for these teams to fight amongst each other, on everything from support models to tooling.
These types of environments force development teams to follow traditional ITIL based manual processes, that could be automated but haven’t because they are managed by the existing On-Premises based teams. I liken this to troops in trenches lobbing grenades to each other whilst the military is slowly running out of ammo and funding. So, how do we solve these issues?
Credit: Knoldus Inc
Cloud Native IT is the way forward. This is not an overnight change, this is not something that can be achieved by purchasing tools. There is a cultural and empowerment movement that needs to occur for all of these issues to be resolved, including a shift in technology choices.
What is Cloud Native Technology?
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 above definition is from the CNCF Charter, which very simply calls out what the aim of Cloud Native technologies is.
This definition tells us What Cloud Native Technology is, but the real challenge is How can we achieve it?
The answer is GitOps.
Weaveworks a founding member of the CNCF has defined GitOps as:
GitOps is a way to do Kubernetes cluster management and application delivery. It works by using Git as a single source of truth for declarative infrastructure and applications
Credit: Weaveworks
I wholeheartedly agree that using “Git as a single source of truth for declarative infrastructure and applications” is the way forward, however, I believe this can also include PaaS based services and even IaaS not just to Kubernetes.
I have again placed my Model below, to touch on the third column, Cloud Native IT.
This column highlights a GitOps approach to Cloud Native IT, where all teams are working across the responsibilities in a shared manner. This is extremely powerful, as it means, for example, that our Security Engineers can look at how we are provisioning servers, storage, networks, etc. without having to delay teams or specific team members as we have decentralised the responsibility.
It is with this push towards Modular Code, Containers as a Service and Functions as a Service, that we can achieve this model. By creating infrastructure patterns and building blocks that enable developers to focus on adding business value and inventing new solutions for the business.
Because of this decentralisation, we have removed issues such as the high barrier to entry, the deep coupling of components and the battles for control and instead enabled:
- Low Barrier to Entry
- Inexpensive to Change
- Exponential Scaling
- Open to Innovation
It is with both the cultural and technological changes that enterprise can evolve from Traditional Services IT Model to a Cloud Native IT model which enables the true value of cloud technology through a GitOps approach.