From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer
635498570651537393-277755902_keep-calm-and-say-no-to-fomo2

Should You Care About Cloud Native?

550 Words. Plan about 3 minute(s) to read this.

To hear vendors tell the story, every enterprise in the world will be running cloud native applications on hybrid cloud networks any second now. In fact, if you’re not already firing up those containers, your business is behind. I mean…gosh…you’re probably losing thousands of dollars each minute because you’re not agile enough. You’ll be doing massive layoffs before you’re done reading this article just to stay alive.

Nonsense.

To understand the hype around cloud networks and cloud-native applications, you have to understand the point of them. Deploy new code quickly by minimizing infrastructure engineering involvement in the deployment process. That’s a simplification, but I think it fairly characterizes the core value proposition of devops and cloud infrastructure.

If you’re a typical enterprise, note that deploying code in this manner does not mean upgrading your MS Windows Active Directory servers more quickly, adding new functionality to SharePoint in some cloudy way, patching Oracle servers, or any of those other things you do to maintain the legacy applications you bought from “Big Software” vendors.

In fact, if you’re not developing your own applications in-house, cloud’s primary use case for you is arguably SaaS.  Not IaaS. And you don’t need a cloud network to run SaaS. You just need a decent connection to your SaaS provider.

The SaaS experience is primarily about changing the application consumption model. With SaaS, you outsource an application and its infrastructure to a provider. Ordinarily, you’d have bought from Big Software and run the pre-packaged application on your own infrastructure. With SaaS, you no longer care about the application’s installation, maintenance, or infrastructure. You pay someone else a handsome monthly fee to care about that for you.

The IaaS experience is largely about changing the infrastructure consumption model. Obviously, IaaS is very much about infrastructure. Compute, storage, networking, security, and availability requirements are still considered. But all of those concepts have been abstracted from physical servers into resources that are consumed programatically.

Clouds — IaaS — can be built privately, running on your own infrastructure. They can be consumed publicly using Azure, Google, AWS, and several others. Or they can be consumed as a hybrid of private and public clouds.

Here’s the thing. I do not believe that the SMB and mid-market making up the majority of IT shops in the world (probably you) are going to shift to cloud native applications soon. The way I see it, you don’t have the problems that the devops movement coupled with cloud is solving. In addition, you have neither the applications nor operations that map to this model especially well.

As a long-time infrastructure engineer (I was a server, storage, and backup engineer before I was a network engineer), I see a great deal of value in devops and the cloud model. It makes sense to me and pushes my nerd buttons. But I am not at all convinced that this does or even can make sense for traditional IT shops consuming Big Software applications. There is not yet a clear migration path for those who do not have their own development teams with applications to deploy.

For the average IT shop, the infrastructure play that makes more sense to me is hyperconvergence. Not cloud native.