My last post about how to fix your private cloud focused on IT’s organisational flaws, ill-directed focus and lack of customer-responsiveness. If I’m going to fling excrement at my industry peers, I’d at least better have a crack at identifying some good use-cases for the private cloud myself, and highlight where the focus could/should have been.
So this post is primarily a bullet point list! Here we go… Private clouds can enable:
- Single OS instances for sand-pitting applications. If a developer needs a server environment, they spin one up in the private cloud, rather than hack their desktop to pieces. The benefit over using public cloud here is that the sandpit will have access to the internal systems a developer needs.
- PaaS-like environments, and by this I mean pre-configured development environments with all the preferred tools and integration technologies already installed. This is a natural extension on the last point. This could also include database-as-a-service (DBaaS).
- Internet-facing applications that need to be spun up, and then down, quickly. The classic example is a marketing campaign. These types of loads may have been handled by a marketing agency in the past. This could be done in public or private cloud, integration depending.
- Internet-facing apps where you want to preserve an architecture that scales when needed (for example a political parties web site which gets hammered once every 3-4 years, or a betting site that gets smashed once a year). Of course some of these would do well in the public cloud but for regulatory, latency, specialty-hardware or integration issues.
- Web portals and e-commerce systems that necessarily combine many internal and external system components. Imagine an e-commerce system that integrates social-login and internal product information systems.
- Web services where utilisation is unpredictable and the service consumer is as likely to be external as internal. Web services typically need access to a company’s data so will likely be “close” to internal data sources making private, rather than public, cloud more likely, especially for large or sensitive data sets.
- Virtual desktop infrastructure (VDI) because workloads are inherently highly variable, which is a good reason for implementing on the cloud. User access to VDI will be from anywhere on any device at any time, which suits private cloud environments. Typically VDI is built on specific hardware, but increasingly integration opportunities between VDI and Cloud vendors are occurring.
- Disaster Recovery/Business Continuity. The public cloud is promoted for this purpose of course, but moving the function in-house could be cost effective for a very large enterprise.
- Platforms that are developed using Agile, Continuous Deployment and DevOps practices. In these instances your infrastructure is part of your deployment process and fully orchestrated. There is typically no “operations handover” in this environment and it evolves over time.
- Systems where you are occasionally grunting through a very large amount of data. For example, 3d rendering, unstructured or big data analysis, and business modelling.
These some use-cases I researched and have observed myself. If you can think of any more, add them in the comments.
One of the interesting things to consider is what is not on the list: legacy systems, Exchange servers, storage systems, Intranet portals… You could put these on your private cloud, but there’s no great benefit. When you factor in the orchestration effort it can actually take longer to get these working on the cloud. They probably don’t need autoscale and other cloud features. So run them on your ol’ VM farm!
IT would have done better to work through the likely use-cases for the cloud and focus on these rather than looking at the private cloud as the latest platform for…. everything. Even better it could have done this before beginning, which leads me to the topic of the next blog in the series: The business case.