Bursting Some Cloud Native Myths
When we combine cloud native computing with DevOps, everything is shifted left. Or at least, this is the golden end-vision that is often held up. Platform engineers optimize infrastructure configuration around different developer needs, they automate it, and offer it up as a self-service menu. A few clicks and developers can get straight down to development, with infrastructure done correctly from the start of the process.
But there are some myths and misconceptions lurking within this vision.
Developers Don’t Care about …
It is a phrase we hear increasingly in the world of DevOps and cloud native computing. Whether it is storage, databases, networking, compute or any other area of infrastructure, we are told developers don’t really care about it. I know exactly what people mean by this, but to me, it is just a bit too flippant.
Developers care most about building great applications — developing software that drives the business forward and helps us stay competitive. Like most professionals, we want to make a difference. Few of us prefer to spend our time configuring storage volumes, building failover architecture or fine-tuning database performance (although the few that do are now increasingly valuable individuals).
But not having to care about something, is a very long way from not caring. Developers realize all too well that some infrastructure technologies solve problems far more effectively than others. Every developer wants access to the best underlying technology that is going to let us build, scale and ensure our application is the best. So developers do care — very much. We want confidence that what we’ve chosen for our application is the best choice.
Infrastructure Is Commodity
Following the trend started by AWS, there is a belief that cloud native computing has entirely commoditized infrastructure: compute, memory, networking, storage — they are all just vanilla resources you draw from the platform.
While there has been a definite element of commoditization, we are seeing a proliferation of cloud native technologies to support individualized use cases. But commodity or not, this is not The Matrix; you cannot just feed these resources directly into your development team through a CAT5 port in the back of their heads.
Any platform engineer will tell you that their job is about automation, yes, but also tooling. The tools, platforms and architectures that organizations use to build on top of public, private and hybrid cloud platforms are becoming a vital source of competitive advantage. As I said, we all realize that some infrastructure technologies solve problems better than others. And this is no different in the cloud.
As I mentioned above, cloud native infrastructure platforms are becoming the very opposite of commodities. Increasingly, they exert the most significant impact on every aspect of the application: from development and operating costs, through performance and resilience, to enabling different architectural possibilities that make an application viable in the first place.
We Have Reached Nirvana
The last major myth on today’s hit list is that a world of cloud native DevOps and continuous delivery (one that now very much includes stateful applications) is some kind of Digitization Nirvana in itself. It is not the end of the journey; it is just a very exciting start.
Any business change management is about maintaining the constant balance among people, processes, and technology. Cloud native DevOps has shifted technology and process a long way. The focus now needs to be on the people, their needs, and feeding this back into the cycle.
There are very real skills shortages emerging, which mean companies not only need to get the most value and productivity out of their team but, perhaps more importantly, show that they value their team the most. In both cases, this will mean choosing new cloud native technologies that really allow businesses to focus on people, first and foremost!
Learn more here.