You know how sometimes you hear or read something and realize that whatever was said could be interpreted in multiple ways? I thought about that when contemplating the title of this post. Please join me as I travel along a few possible paths of meaning.
A literal interpretation of “Managing Analytic Workloads with Cloud” could pertain to the topic of administering a system deployed in the cloud, the purpose of which is to do analytics. The thrust of this path might discuss the benefits and drawbacks of an as-a-service environment when compared to a do-it-yourself deployment, for example.
As-a-service implies a managed environment in which the service provider takes care of the infrastructure while the customer focuses on using the capabilities that run on it. It’s like having a race car pit crew that comes with your vehicle to handle all the little (but necessary) details like tire tread depth, proper tire pressure, working instrument panel, clean windscreen, and topped-up gasoline to give you the best possible chance of winning the race.
Do-it-yourself, on the other hand, implies that the driver take care of everything his- or herself (or hire and train individuals to do some or all that work). It’s not necessarily better or worse, but depending on one’s skill, experience, and proficiency, the ability to go both fast and far could be limited if all you have is your own toolbox. But it can be done.
A literal interpretation of “Managing Analytic Workloads with Cloud” could pertain to the topic of administering a system deployed in the cloud, the purpose of which is to do analytics.
A second interpretation of “Managing Analytic Workloads with Cloud” is a bit more meta – as in deciding which workloads will go to the cloud and which ones will remain on-premises. The thrust of this path involves picking the right environment for the job regardless of who is going to be managing those capabilities as discussed above.
For example, the cloud is an ideal environment for workloads that are not persistent, such as test/dev or discovery analytics. With the ability to spin up quickly, use as much as need, tear down or put to sleep when done, and pay only for what’s been used, the cloud is wonderful for such bursty workloads. These are the poster children of cloud.
The opposite is also true: persistent, semi-steady workloads in which you commit to persistent resources with a term subscription (to get a much lower price) can also be a good fit for the cloud. This is especially the case if there are “network effects” involved – as in myriad other services, data sources, applications, and similar benefits that naturally draw you and your user community to the cloud. Everyone likes a good watering hole near the office.
Centralization (at least from a logical perspective, if not a physical one) can make a lot of sense here – or not, depending on how much on-premises data, applications, and technical debt is at play. There is no one-size-fits-all, and the right choice is typically a function of business priorities, timeframe, and budget.