Tell us more

Community

Hurtling Down the Mountain of Infrastructure Best Practices

Hurtling Down the Mountain of Infrastructure Best Practices

I asked Kendall how he felt about the rapid paradigm shifts of "modern best infrastructure practices" and his response was enlightening: "I'm on a ski slope."

Skeptics may claim that Kendall was taking a day off skiing in Colorado, but I would assert that you're unfamiliar with Kendall-- a man whose first language is Glorious Metaphor. The more I thought about this sage statement, the more sense it made.

In 2006, the best practice was to look at converting your endless racks of bare-metal machines into some form of virtualization. Divorcing applications from their underlying hardware was the next step-- ask any technologist.

In 2012, the best practice was to convert those racks into instances in some public cloud provider's environment. Converting CapEx spend to OpEx was the right move-- ask any analyst.

In 2015, the best practice was to migrate to DockerDockerDockerDockerDockerDockerDocker-- sorry, my transcription software got stuck. Migrating to containers was the thing that made the most sense-- ask any evangelist.

Today, the best practice is to migrate to some form of container orchestration. Being able to programmatically "schedule" your workloads into an application-agnostic infrastructure was the way forward-- ask any venture capitalist.

Soon, the best practice will be to migrate to "serverless" technologies, but I'll come back to that particular point in a future post.

Today, the question arises... what if you missed one or more of those shifts? "Rewrite your legacy Rails application into something stateless" sounds like a great best practice, but in isolation it's potentially a yearlong project that adds no business value. Businesses succeed or fail based upon market forces; very rarely is "they used the wrong infrastructure technology" one of those market forces.

So what if you ignore the hype train-- what if you don't move towards containers, towards Functions as a Service, towards a microservices architecture that gets your company written up flatteringly in the in-flight magazines? What consequences exist for that?

Technology has to empower the business, or it's not viable. "Because it's cool" stopped being a business case in the first dotcom crash. But these tectonic shifts in how we collectively think about infrastructure aren't just massively disruptive to our own operations-- they're speeding up as well. We’re out of control-- almost like we’re hurtling down a mountain with no idea how to stop. We can’t understand the “why” behind these changes, we just know that if we don’t do them, we’ve failed. If you're looking at the current state of the art in this space and feeling completely overwhelmed, you are absolutely not alone. Keeping up with what you "should" be doing has become a full time job.

ReactiveOps's philosophy around this is that you shouldn't be worried about these things. Worry about your business. If what you're doing today gets the job done-- if you're able to hire effectively, able to run your environment stably, able to respond to your customers in a way that leaves them delighted, then you shouldn't change a thing. Find the technology that works for you, not for the rest of the world. ReactiveOps has always been about empowering business, not technology for the sake of technology itself.

But if Kendall doesn't come back online soon, I'm going to send out a search party.

Other Thoughts Posts

| ReactiveOps

How We Deliver Big Even Though We’re Small... With DevOps-as-a-Service...

Read more

| ReactiveOps

Bridging the Chasm: Exceptional Application Performance Requires Dev Insight and...

Read more