CTS Loading

The Developer & Engineer Experience, Vital for Cloud Adoption

26 November 2020
Overview

In this blog, we'll be covering the role of people in cloud adoption, particularly developers and engineers.

I've been talking about this topic for some time (over 10 years), but I have to admit I'm not a developer, and some may argue only an average engineer! So why am I writing about the topic of developer bias? Well, it stems from questions many of our customers pose, including things like: “Which Cloud is the right for us?” “Should we be multi-cloud?” “We've always used Microsoft, so we should use Azure?”, “We need Kubernetes at scale so we need Google?”, “the AWS rep keeps calling, maybe we should use them, they are the biggest right?”.

To my mind there are a number of aspects to choosing your cloud;

  1. What industry are you in? e.g. many of our friends in the retail sector aren't fans of AWS due to the competition angle
  2. What types of regulation / compliance are you subjected to? In some cases there is a geo-aspect to this - does the vendor have a local region?
  3. Price and commercials
  4. What support is available? How vibrant is the support and ISV community around the platform?
  5. What are the green credentials of the platform, will it help me achieve carbon neutrality?
  6. And lastly, cultural alignment > what do your developers and technologists actually 'want'? What do they get excited about, what will enable them to get creative? to update existing apps, make sense of your existing & relevant public data stores and well, ultimately be happy(!)?

Now while I appreciate all points, the last one around ‘people’ is to my mind the one element which is so often missed (or at least not prioritised). Companies obsess over Cloud Centers of Excellence (CCoE) and concentrate on 1-5, which demotes the developer choice to the bottom of the queue. What a shame, to my mind it should be in first place.

All three of the leading cloud vendors are at a stage of maturity, whereby (with some niche exceptions) they all have a strong and broad set of features, an excellence stance of security, governance and are delivered at a fair price point.

So, there’s parity on the basics, but I would argue fundamental differences when it comes to your grass roots developers and engineers.

I met with Drew Firment back in 2018 (ex Capital One, now at A Cloud Guru), we were discussing Cloud Adoption and the topic of training and enablement. He was explaining how as an organisation, Capital One were putting a huge amount of effort into their staff, helping them to unlock and discover their passion for the Cloud. The framework they created was super successful, to the point where this week they announced that they completed the shutdown of their last traditional data center, this week. Kudos.- Not easy, but I would argue easier when you tap into your development and engineering communities’ desires and passion to build and modernise. I'm a firm believer that this pivot will set up Capital One for future success vs their peers. (Drew has since left and joined acloud.guru to continue to pursue his passion for developer / engineering empowerment and training!)

The DNA of your developers and engineers will vary depending upon your history, the technology stacks you use, your personal 'feelings' towards technology. You should tune into this, I'd argue you cannot force technology choices. Early in my career, I was the original Microsoft fan, I spent my time decommissioning Novell Netware, Groupwise and moving to Microsoft NT 4 / Exchange, became an MCSE. I loved it. Over time, especially through the Steve Ballmer years* (not the best..) / the wider community move to open source / the emergence of hyper-cloud providers, my attitude changed. I wanted something different, I wanted to be part of a broader community, with a positive and forward-looking view.

In full disclosure, I've worked with all three of the big players: Google, AWS and Microsoft (sorry Oracle...). In my current role, I work with Google and only Google. As a dedicated Google Premier Partner, we wear the branded t-shirts with pride, it's deeply ingrained in our organisation. We're passionate about technology, the contributions Google makes to the open-source community and we actively want to engage with our customers' grass roots engineering and development teams.

CTS’s mission is 'Our customers want to differentiate from their competitors by leveraging Google’s technology and culture of innovation. CTS’s mission is to spark, enable and empower just that.' We want to tap into and support those organisations that feel that pull from their teams to innovate with Google tech. It's infectious when you get started!

In conclusion, listen to your developers and engineers! Get them involved in the process, their input and enthusiasm is essential to the collective success of your Cloud Strategy.

*Sataya Nadella has done an exceptional job since SB!

 

Recent posts

Kubernetes Part 3: Secrets

In the two previous posts in this series, I have discussed security in GKE - starting your...

Taking Back Control: Policy enforcement on Kubernetes

"Kubernetes is an amazingly powerful platform” 

 

Quick fire Questions with a CTS Project Manager

What’s your role within CTS? And what career steps did you take to get here?

I am a Project Manager...

Recent posts

Kubernetes Part 3: Secrets

In the two previous posts in this series, I have discussed security in GKE - starting your...

Taking Back Control: Policy enforcement on Kubernetes

"Kubernetes is an amazingly powerful platform” 

 

Quick fire Questions with a CTS Project Manager

What’s your role within CTS? And what career steps did you take to get here?

I am a Project Manager...