I started my career 20 years ago as a software engineer. A lot of us—and I know I’m not alone—have witnessed the unprecedented growth of the public cloud and continue to do so today.
There are cloud providers that have an opinionated view of how you should build with them. We call this approach platform native. They want you to build in a way that uses their services and their tooling, all within their ecosystem. But cloud providers shouldn’t dictate how you build and deploy. Instead, your workloads should be portable, using open- and standards-based tools that allow you to deploy and move them wherever it makes sense to find the best geographic, price, or performance fit for your workload.
Today’s Developer Buying Journey
I’ve made mistakes when selecting the right cloud provider. Many of us have. But these experiences—good and bad—have allowed me to see patterns in the selection process. And I’ve discovered five stages in a developer’s cloud buying journey.
1. Discover. Whether you hear about something new at an event while reading Stack Overflow or a Reddit thread, watching YouTube, or wherever, a cloud service will pique your interest because you’ve never heard of it before. And suddenly, you think: What is this? How is this applicable to me? How can it help me?
There are tons more questions to ask during discovery. Your goal should be to get answers about what makes a cloud offering unique, what differentiates it from something perceivably similar, and the specific value proposition it presents to you. Whether it’s a commitment to service or something else, it’s here when you ask, “Why?”
2. Evaluation. At this stage, we’ve moved past wondering and are pretty sure there’s something here. It’s now time to commit and evaluate what we’ve discovered. Don’t plan a big time commitment. It usually only takes about 15 to 20 minutes to dive into documentation. But you’ll need to dive in deeper to understand the service or tool and evaluate any differences from what you already know.
While it helps to understand exactly what services you’re evaluating, don’t worry if your knowledge of other cloud providers is somewhat narrow. For instance, take our managed Kubernetes offering. If you’re familiar with competitive offerings, you can draw some comparisons between those and Linode Kubernetes Engine.
Here’s an excerpt from an evaluation use case from Elliot Graebert, Director of Engineering at drone manufacturer Skydio.
“The interfaces look fairly identical, making it impossible to declare one better. Their design is crisp and clean, without the feature bloat prevalent in AWS and Azure. In my opinion, this simplicity goes a long way to helping you get in, deploy your app, and move back to writing code.” He adds: “Linode’s incredible speed for booting up new k8s clusters will appeal to some audiences, and their overall node deployment time was solid.”
3. Learn. Now we’re ready to move to the most crucial step. And the reason is that, during the evaluation stage, you’ll invest some time, but this is when you will invest most of your time. As developers, we have a million projects running through our heads. Now, we’re going through a bit of a fitting exercise to see if this cloud offering is worthwhile. Be prepared to invest hours in learning. The biggest question to answer is: Will this cloud provider and their solution work for my next project?
4. Build. What engineer doesn’t love to put their hands on a keyboard? But this step is where things often go wrong. We conditioned ourselves to build MVPs (minimal viable products) when we really need to build MLPs, “minimal lovable products.”
MVPs are the bare minimum, and you’re not going to like them necessarily. Out of all the MVPs I’ve built throughout my career, I can’t name one that was fit for production. In my role today, I love showing developers how to create an MLP. The result is something they can honestly evaluate whether or not the effort that they put into building it was worth the result.
5. Scale. There are so many questions that you’ll ask at this stage. When understanding scale, you’ll want to know how to take advantage of multiple regions, whether to replicate data from one point to another for disaster recovery or just to exist in more than one region. Think about scale not just from a process perspective but a personnel perspective as well. If you need to inject more people into this process, what does that look like?
You’ll also want to understand the integration process. Whether through a CLI or API, find out what is available that can help you automate. We’re in this wave of automation with Infrastructure as code (IAC) leading the way. We’re doing more with less because we know processes scale and people do not. Evaluate the effort it takes to stand up the Infrastructure and scale.
Platform Native Versus Cloud Native
Cloud choice will continue to be an evolutionary journey. We need to start looking at it more objectively. When I first ventured into the cloud, I built exclusively with those platforms and tools. All the technical literature available at that time was about a particular platform. But as I grew as an engineer, I started to build in a cloud native way where I could pick up my workload and move it wherever, giving me more control over the things I built. And I did that with the help of open source tools, which allowed me to adopt unified standards such as CI/CD, IaC, and containerization.
If all of this aligns with your way of thinking and you want to build in this cloud native way, we’d love to talk to you. Reach out to me or any team member to discuss your cloud buying journey.
Comments