Story of Mr. IT & Ms. Cloud

The way you think and operate your infrastructure and private cloud, is crucial to how your organization perceives and utilizes new technologies.
IT Architects often overlook the term ‘Cloud’ as a buzzword, rather, a pattern of deploying infrastructure.

Automation, blueprinting & orchestration… they’re all OK. But, they miss some very basic truths about what cloud is at it’s core.

Previously, we revisited the term “Hybrid Cloud”, and determined why it should be used more accurately, embodying the fact that enterprises should adopt and take advantage of the cloud model offered by Public Clouds.

This is where most blog posts around this topic will raise the ‘cattle vs pets’ arguments. Though I agree, I’d like us to dive a bit deeper and have another perspective. The way I see it, it’s not necessarily about the ‘pets’ themselves, but rather their owner – Mr. IT.

Thinking like Mr. IT

What Mr. IT had done since the dawn of virtualization, (and prior, in the x86 native era) was to do what ever it takes to make common infrastructure, such as disks, compute, and memory to become more & more resilient. Throughout the years, IT departments had paid billions and trillions of dollars in hopes of making infrastructure fault-resistant. Investing in redundant networks, clustered computing, and smart storage machines that can often replicate seamlessly between data centers (Metro Clusters, VPLEX, and their friends) all of which, end up costing a lot of money.

Mr IT, had a very good reason to do all of the above. Applications built in the client-server era, were architected as monoliths, and virtualized as-is from the days of early x86 rack servers. In this world, scale-up is the prominent methodology. Mr. IT continues in building his redundant hardware layers, increasing app (and business) performance via means of adding better compute / memory / storage.

While you can argue that these kind solutions pay off as they aim to eliminate business critical outages, today, more and more disruptive technologies & patterns allow developers to shift the old app paradigm. Eventual consistency data models, NoSQL, Micro-services etc, all allow and require infrastructure to be treated differently.

Thinking like Ms. Cloud

Public Cloud, as it’s provided today by amazon AWS , Azure, and GCP, is an implementation of an infrastructure deployment pattern. This pattern is very straight forward. Instead of saying – “My infrastructure will make sure that no workload will ever fail”, It uses a different line of thinking. One that says: “I know that my infrastructure might fail, but if it does, it’ll be contained in this specific area.” This, is the paradigm used by Ms. Cloud

When AWS took this approach to sell IaaS (and later on, other services) they didn’t just invent a new pattern of deploying hardware, but in fact they created a new paradigm for developing software, by putting the availability ‘burden’ mostly on their customers – software developers, rather on the AWS ‘Cloud Service’ IT team.

This same paradigm, can and should be implemented in the enterprise. However, it does require a management mind shift, and the correct tools.

When Amazon’s own S3 storage fumbled last march, most complaints we’re towards App developers such as Slack, Giphy, etc… Not developing for redundancy. No one was really pointing a huge blaming finger at Amazon, since as long as S3 kept it’s 99.9% availability of infrastructure SLA, Amazon have kept their part of the bargain.

And this, is where Service Driven Infrastructure comes into play. If your developers have full visibility  into understanding the extents of your organization’s infra, capabilities, limits, and fault/availability zones, they would and should, take it upon themselves to guarantee proper application redundancy.

More importantly though, their managers, peers, and IT Administrators, should drive them to do so.

Thinking like Ms Cloud, often means:
1. Offering self service infra, with visibility into underlying constructs, such as clustered racks & storage pools.
– This will serve your devs in knowing where & how to deploy services, and architect their software.
2. Supplying with general-purpose building blocks, that allow developers to build modern apps.
– Redundant Storage, Network, Compute, are the building blocks of the client-server era.
– Cloud native era building blocks consist of – DBs, Queues, LBs, and Name registration (often for micro-services discovery capabilities)

Conclusion

As a CIO, an IT Manager, or a system admin, you should always consider the costs of your infrastructure. Try to determine whether your developers make the best use of it. When infrastructure down-time occurs, and heads are flying, ask your CTO / R&D Managers whether they would blame IT for an Amazon cloud outage.
The first shift in making Private Clouds great (again), is to treat them exactly the same way as you would a public cloud.

Finally, Lets conclude with a thought experiment. What’s the cheaper, most cost-effective option?

1. Spending $2M worth of SAN storage rack, including it’s fabric, with a premium hypervisor attached to it.
2. Rewriting the app using your infrastructure, using 10 software engineers in a 1-year project.

Should you invest time & money in maintaining top-tier hardware, or in modernizing your business & process via software?

To Be Continued …


Comments
Harvey Specter
Posted at 12:01 pm April 25, 2017
ziv
Reply
Author

Leave a Reply to ziv
Cancel Reply

Navigation