How to fix your private cloud – Part 5

In parts 1-4 of this blog series we explored some reasons why private clouds bombed. In this final blog, I’d like to discuss a better approach

Finding examples of successful private clouds is difficult because many organisations claim to have a private cloud when in fact all they have done is install VMware. If a project manager has to organise a resource to install something it’s not a cloud. Cloud is not virtualisation.

If you were starting a private cloud environment build 3 years ago, it would look different to one you would begin building now. But I like to live in the here and now so let’s look at what we would do now.

For starters, reverse these unspoken principles:

  • IT departments do not need to communicate with their users.
  • IT departments are needed and irreplaceable.
  • Users don’t know their needs and IT departments do.

Then approach as shown below. Users care about the items closer to the top.

Private cloud approach

Now, look at your best use-cases and choose a champion project/platform/department to partner with so you can create one end-to-end service.

Then get the right people on board to build it out. The guy who built your virtualisation stack back in the naughties probably doesn’t have the social intelligence (and hygiene) to approach users and “communicate”. Users value the speed in which resources can be allocated to them, the simplicity of getting their work done and the lack of friction involved so put someone in charge who understands public clouds, understands service design and delivery and is willing to start with an open mind. Then create a list of services you wish to offer.

Eventually after much work and discussion you’ll get to the point where you understand the services you want and what is required of the technology to support your cloud. This is where you may get derailed. Whatever happens make sure your choices minimise “tinkering”, promote scalability through modularity, and can work with your current network.

Your network may suck. It may make providing access to external and internal users difficult. It may be impossible to converge data and storage networks. If so, you could wait for SDN to mature and your CIO to give you budget for a Network Refresh or…

  1. You could build the cloud off-premises. Private cloud is used only by internal users but can be built anywhere. So build it in Rackspace or AWS, or a local provider if data sovereignty is an issue.
  2. You could build the cloud on converged infrastructure which includes its own networking. Something like vBlock or FlexPod. Converged Infrastructure is modular, making it easy to add and manage computing power, storage or networking throughput. The seamless coordination between hardware manufacturer (compute, storage and networking) and virtualisation is key to private cloud computing. It resists “tinkering”.

You’ll need more tools over time to manage this because of new standards and platforms, capacity-managing a pool of resource aggregated at a data-centre level, and also in planning for the hybrid cloud (which may exist for real one day). But all in good time.

The cloud is essentially a vending machine. It’s an automation-oriented, self-service approach to IT. Anything else is folly.

Businesses that run on the cloud: Annex Products

I ran into Rob Ward at a recent StartupGrind and he came across as very personable, relaxed and successful. He is a Founder at Annex Products, who make the incredibly popular Quad Lock cases for mounting smart phones on bikes, cars and people.

We caught up a few days later for a coffee near his office in Prahran. The Annex office had a cool set-up with ping-pong table, arcade machine, 3D Printer, quadcopter and lots of prototypes. His team were working behind 27-inch iMacs running Solidworks for CAD and for everything else it was the just usual Dropbox, Pages, Numbers, Adobe Creative suite and Final Cut Pro.

I intended to ask him about the different platforms they used to manage and run their business, but we spent quite a bit of time talking about sales and marketing. He sees Annex as a brand and product design business. Great design is important but “isn’t enough to stand out from the crowd”. You need good sales and marketing.

Rob learnt sales and marketing the hard way (or the best way he’d say). In the mid 90s he was out walking the streets selling OptusVision cable TV to Australians. I remember thinking that was a horrible job at the time but Rob reckons it gave him the best possible sales education. Maybe I missed out!?

The best sales and marketing tools Annex use are Facebook Ads, Email lists – “the best customers are return customers” – and AdRoll, a “retargeting” platform. Retargeting works by keeping track of people who visit your site and displaying your retargeting ads to them as they visit other sites online. That’s important because many people don’t buy the first time they visit your site. They just need a little reminding!

Some of the other key systems/platforms they use are:

Crowdsourcing:

Kickstarter: He had to perform some magic in setting up a prerequisite US Bank account to get started, but this step got the ball rolling and “proved” there was a market for their product. (The US bank account issue does not exist anymore, at least for Australians.)

eCommerce customer interface:

Shopify is the businesses storefront. Rob mentioned how easy it was to set-up and use – “Why would you build your own?”. They use Canadian developers to tailor the site (Responsive design etc.). Why Canada? Because Canada has great Liquid developers. (Liquid is a templating language for Shopify). Previously they’d sold Opena cases on a “cheaper solution” (not Shopify) and then one day Ashton Kutcher tweeted about them and knocked their system over. The ecommerce platform provider at the time gave them as much infrastructure grunt as he could and they still fell over. Shopify has never had this problem.

Payments:

Paypal and Stripe (which only just kicked off in Australia making it easier to use accept payments from anywhere in the world).

Fulfilment:

Shipwire: You previously needed a US account to get this started just like Kickstarter. It’s easier now. Shipwire integrates with Shopify, and a heap of other commerce systems. They store your products in their warehouses, provide shipping rates and inventory back to your storefront, arrange delivery etc. These guys are crucial if your business ships a physical product.

Customer Support:

Zendesk: Keeps track of customer issues and details. As the Annex business hit scale, there was no other way to keep track of this stuff.

CRM:

Capsule CRM: Annex primarily use this to manage relationships with their B2B customers.

Accounting software:

Xero: Accounting SaaS provider. Cool… but it’s still accounting.

List Management:

Mailchimp: Manage your email lists.

All of these platforms are software-as-a-service. The ecosystem they play in has forced the major players to integrate well with each other. This truly is a business without on-premise IT (apart from their iMacs).

Rob takes the approach of “do and change” with his business so he’s not too concerned about change. If a SaaS provider they use started to alienate their base or went out of business I imagine he’d take it in his stride and move to someone else. Possibly a few late nights and stressful moments, but Annex would get through it.

One thing he kept iterating was how easy it was to set up these businesses.

So check them out. It’s a great example of a contemporary global niche business, where the barriers to entry get lower and lower.

Start your own business. Looks easy enough!

How to fix your private cloud – Part 4

We’ve covered legacy IT, use-case and business case issues. Today we’re talking about the immaturity of private clouds themselves.

There are 4 areas where private cloud deployments haven’t matured yet that you must contemplate:

  • Software licensing – When migrating legacy software to private clouds it gets very difficult to track software licensing. Where previously you had a pretty static license pool, in a private cloud your usage may expand and shrink. How do you manage that? For example, how do you deploy Oracle RDBMS in a private cloud if you don’t have an Enterprise agreement? A nightmare!
  • Lack of standardsThere are many cloud platforms, some proprietary, some open-source. All these are different to their public cloud companions. It’d be good if a public service provider would let you install your own cloud platform on their tin. It’d make hybrid cloud a lot easier. One day I suppose. Until then you have to manage your public and private APIs differently.
  • Compliance leakage – Your private cloud is a single environment. Anything that has regulatory or compliance requirements (like PCI-DSS) can’t go on there without bringing the whole cloud into scope because of…..
  • The immaturity of cloud networks – I know SDN will save the world but for now the underlying networking concepts of different clouds are of a differing standard and sophistication. Many enterprises therefore deploy cloud networks in a basic, pre-provisioned fashion. (Read about the 6 challenges of private cloud networks in this F5 document.)
11144223_ad706710a5_b

Mike DiStaula, little boy (Mike Burns via Flickr)

I suspect one day cloud platforms, standards, licenses etc. will converge enough so that you are running the same technology in private and public cloud stacks. Possibly AWS will provide an on-premise cloud stack, or a provider will start letting you install your own cloud platform as already mentioned. At least with this last one, the enterprise is finally free of the need to actually deal with hardware. What will we call infrastructure specialists then!?

The default answer is that IT’s vision is to provide hybrid or “multi-cloud” environments but not many people can actually articulate what that means, how it can be achieved, and why business users should care.

In the last post in this series we’ll look at the ways forward.

How to fix your private cloud – Part 3

In the past two blogs we’ve looked at the inertia of Enterprise IT and the issues with use-case development for private cloud. Today it’s the business case.

Business cases are typically written for, and approved by, senior management who don’t fully understand technology – its possibilities and limitations. They use IT services more than most demographics and always want the latest tech – for themselves at least!

So what is the business case for private cloud?

Is it to increase revenue? Possibly, in some indirect not-so-obvious way.

Is it to decrease costs? Not at all, unless you were really inefficient to begin with. It does reduce the transaction cost of establishing a new platform but that is but one smallish component of a projects cost. Building a private cloud requires a big upfront investment with no immediate return, a real “field of dreams” situation. Cloud is about speed, automation, self-service and a little experimentation.

http://johnhoran1917.files.wordpress.com/2012/07/552976_154631554667905_372989070_n-copy.jpg

A business case must be able to measure and demonstrate success. You need a metric and it’s difficult to measure cost reduction or revenue improvements with a private cloud. You could use project delivery and time-to-market metrics. You could measure how many applications are running on your private cloud. You could measure developer satisfaction and/or usage. None of these metrics are easy to measure or necessarily translate to a successful outcome though. If project delivery times go down is it related to cloud or other improvements? If you measure how many applications are running on the cloud is it just shuffling your existing portfolio around?

The truth as I see it is this. IT has to transform to meet modern requirements and Cloud computing is one necessary component. Disruptions like big data, mobility, wearables, gamification, social networking, high speed networking, Internet of things, global logistics & resourcing can’t be delivered effective using traditional IT.  Practices like Agile and DevOps – and other things – complement cloud computing for these same ends. IT now plays in a border-less environment with abundant resources, nimble competitors and changing technology. The game has changed.

So cloud is one piece of an IT transformation. But why a private cloud? It’s hard for business users and developers to get excited about internally provided services they can get from Amazon, Rackspace, Google or Microsoft already. Enterprise IT wants to demonstrate robustness, stability and change control but users really only care about usability and provisioning times.

To demonstrate the value of a private cloud you need to demonstrate success in the realm of all this disruption and it has to be something that is difficult to do in the public cloud for security, legal, integration or performance reasons. Choose a significant project/platform in this realm, and bolt it to your private cloud project. A champion project for your cloud.

Your business case then includes a complete end-to-end platform and the success of the private cloud is tied to success of the champion platform, by how well the platform is “harnessing change for competitive advantage”. For example, how do the release cycles compare to your existing platforms? What are the scale limitations? How easy is it to add features and fix bugs compared to your legacy platforms? How well does it perform in the digital world? Do developers use the private cloud? Can users get at the data anywhere and any time? What is the next project that could benefit from this approach?

The business case for a private cloud stacks up only if you have a significant partner at the beginning, or at least very early on. This could be a significant project, application or business area. Sure, run some proof of concepts to familiarise yourself with cloud technology but then get this key user who can provide feedback on the platform, someone who can do regular releases on the platform, someone who depends on your cloud to run their business. This partnership could then be the seed for a new digital enterprise.

In the next post we’ll look at all those thing’s private clouds can’t do!

How to fix your private cloud – Part 2

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.

"Wait here until you are useful",  Matt Brown (via Flickr)

“Wait here until you are useful”, Matt Brown (via Flickr)

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.

How to fix your private cloud – Part 1

Private clouds are difficult to build. In this blog series I’ve surveyed all the common flaws in private cloud design and implementation so you don’t have to chase them yourself. Hopefully you can relate to some of the issues and contribute your thoughts in the comments. In the final blog in the series I’m going to attempt point a direction forward, to fix the private cloud, and share my reading list.

Today’s blog is about the organisational flaws exposed by the private cloud trend.

*********

IT built the private cloud IT wanted to build and not the cloud anyone wanted to use.

Private clouds were commonly seen as an extension of virtualisation. This encouraged IT to have an inside-out cloud mindset. Now virtualisation and cloud typically go hand-in-hand, but they are not the same thing. Even though the IT infrastructure deployed in both instances is usually quite similar, from a user perspective they are completely different. Clouds are quick and self-serviced whereas virtualisation by itself is not. The truth is you can have a cloud without virtualisation. For example, if you build self-service etc. on top of an Oracle RAC Cluster you could have DBaaS. (Be careful to not get screwed too much on the licensing costs.)

IT built the cloud it wanted to build

The virtualisation trend also exposed some organisational issues, which may or may not have been dealt with. It’s part of the phenomenon of Software eating Infrastructure. Virtualisation allowed cloud engineers to make network changes to “soft” switches and firewalls. It allowed them to deploy storage. Storage I/O problems occurred because of poor workload balancing and live migrations. The opportunity to improve IT efficiency by delegating storage, compute and network activities to a semi-orchestrated cloud team existed. In some organisations this change worked, in others it was resisted.

The arrival of private cloud progressed these organisational issues further with many organisations merging specialists into a cloud team and hoping they would abandon their specialist mindset.

I’ve drawn up a very generic cloud stack below:

Private Cloud effort

You should have put most resources into the top block but these skill-sets (establishing services, APIs and managing a relationship directly with cloud users) are not something specialist IT staff are traditionally good at, or have ever had to do. IT shops started reinventing themselves to make this shift.

The bottom two blocks play to IT’s traditional strengths. Depending on how (in)efficient you were you may have spent most of your time and energy stuck in the bottom block, building networks, hypervisors and customised operating systems. If you were still heavily silo-ed there was no way you could match someone like Amazon’s scale and efficiency. Even if you were uber-efficient you probably can’t match AWS. The thing is, if you’ve spent most of your energies in the bottom blocks, and not in the top block, you probably don’t have many users. You spent a lot of time building the “undifferentiated heavy lifting”, as Adrian Cockcroft said back in the day, because it’s what IT knew how to do.

In the next blog post I’ll discuss the business case for private cloud and some use-cases.

MBAs kill IT with efficiency pr0n

If you feel like a good read pick up a copy of Antifragile by Nassim Nicholas Taleb. Specifically read Chapter 3 temptingly titled “The Cat and The Washing Machine”.

A summary of the book in one line is: Antifragile things get better under stress. This is distinct from fragile things that break under stress, and robust things that persist.

Some antifragile examples used are:

  • Human bodies that improve under certain levels of stress (eg. strength training) and;
  • The airline system, which gets better with each single accident. Each accident improves the system (MH370 may prove to be an exception).

Chapter 3 argues that antifragile things tend to be organisms like “The Cat” whereas fragile things tend to be like the “The Washing Machine”.

What does this have to do with IT Infrastructure? Historically we’ve aimed to build robust infrastructure. We’ve built environments with dual power supplies, backup data centres and RAID disk arrays. We build environments to be robust under stress. They don’t improve.

When IT hardware was expensive and scarce it may not have been justified to buy back-up hardware. You may have bought a single mainframe for one site, leaving your business exposed to a potential extended outage. That is, fragile.

Now in the days of IT abundance, IT infrastructure is vast and geographically dispersed. If one server dies in the cloud does anyone notice? Shadow IT, iPads, BYOD and opportunistic vendors make IT growth much more organic that it once was.

It isn’t urgent if a power supply or HDD dies anymore. What is tricky is understanding the complexity of key business functions and how they map to IT. Also, software is eating infrastructure. Physical assets can be robust, but never antifragile. Software is much more malleable and can improve.

As an aside I chatted to a lady at a cafe the other day. She was a nurse about to study LEAN. I was horrified. LEAN is all about minimising waste and maximising value, or in my mind, managerial efficiency pr0n. I imagine the LEAN consultants received less-than-lean money from the public health system. LEAN works well for manufacturing, but applying a model born out of Toyota to hospitals is MBA madness.

I have nothing against efficiency. I just don’t think LEAN works outside of manufacturing. In manufacturing you have slow-changing product life cycles, mass production and well understood customer needs.

Applying LEAN thinking to IT assumes IT is like “The Machine” where in fact it is becoming more like “The Cat”. In IT we don’t fully understand customer needs so we have tight iterations and close proximity to the end-user (ie. Agile). Product life cycles can be incredibly short. Look at mobile apps. Digital software products are not mass-produced. A single version is produced that copied/distributed one-by-one as needed. A large portion of IT work is not documented. It is done by skilled artisans who don’t see the point of writing down stuff for efficiency experts.

In the naughties IT was consolidated to achieve scale. It was then optimised using methodologies like LEAN and outsourcing to manage cost, but IT never simplified. Complexity is always, at least, preserved it seems.

LEAN, consolidation, outsourcing. We ended up with many gutted-out, off-shore script shops. A disaster waiting when something undocumented or unexpected occurs. Previously salaried employees returned as contractors. IT in some ways became more fragile.

In fact, Taleb argues, and I agree, excessive size, efficiency/optimisation and complexity generally makes things more fragile. Efficiency leads you to put all you eggs in one basket. To lean on single vendors (pun intended) and have big hidden risks. Times have changed. Efficiency is becoming dangerous.

That’s not to say we gold-plate IT. I like Agile. Even though it not always implemented well, Agile recognizes IT as “The Cat” it is. It works with small teams, learns and improves (fails fast) quickly.

I suspect a good number of IT professionals will continue to balance efficiency/fragility with robustness when in fact the we should start looking at anti-fragility. We should look at more ways for IT to improve itself under stress.

We want failure to make IT better and stronger. Isn’t this the big takeaway from ITIL problem management? Isn’t this what Chaos Monkey does for Netflix? A non-functional process destroying things at random to improve the Netflix ecosystem.

What other examples can you think of where IT improves itself under stress? And do MBAs with the latest efficiency fad represent a risk to IT systems?

Is the cloud just… web services?

My work colleague turned around to me and said, “Web Services aren’t APIs”. That didn’t sound right so I started investigating. What is the difference and why is it important?

Applications have been built and constructed from re-usable and shared components since the bloody epoch. It’s why software is eating everything. Once a standard interface – and usually a corresponding library – is agreed upon there’s little reason to go back to first principles again. It’s division of labour, driven by pure need, evolving organically.

Then along came ubiquitous, always-available connectivity and expanding bandwidth. Why bother compiling and distributing an API/Library when the same API call could be made to a shared network service? A web service.

So a web service is a type of API. Not all APIs are web services though. APIs are the public interface for a piece of code – it is what you can call from within your code. It may be a web service, but it could also be a Java library or similar.

Wikipedia has a web services as “… a software function provided at a network address over the web”. That’s a pretty good definition. It must also be loosely coupled, which means that both the service caller and owner agree on the interface but know little about each other. The back end class can be substituted as needed.

Companies are themselves creating their own web service APIs. Here’s an API for business listings at Australia’s Yellow Pages and here’s one I’m looking at now to do some useful work on my expanding Evernote database. Both of these are web services with some extra API management capabilities. Grab yourself key and start developing!

Amazon was miles ahead of the curve on this. This famous post by Steve Yegge describes the famous Jeff Bezos mandate (in 2002!) that all teams at Amazon must:

  1. Expose their data and functionality through data services,
  2. Teams must communicate only through these interfaces (no direct database links etc.),
  3. All interfaces must be designed to be accessed externally

and a few other things. Talk about ahead of the curve.

It’s the future mesh of interconnectivity. One big “programmatical” mash-up.

There are the web services you own and the ones you don’t. With regards to the ones you do own, you’ll have to think about how you maintain some control of the integration. Two possible models are shown below. Do you have an integration bus/relay/proxy in each cloud so as to minimise network traversals, or do you have a few centralised integration points to make control and standards (and non-functional requirements like logging, access control, templates etc.) easier.

Web service cloud options

For the web services you don’t own but use, how much do you rely on single vendors, how do you manage keys and how do you manage different standards/skill sets etc.

I’ve always thought of “The Cloud” as a technology theme that is behind many new implementations, but I’m starting to think “the Cloud” is just a biblical plague of web services. It’s even hidden the in term “as-a-service”! All SaaS, PaaS and IaaS providers have public web service APIs built in from day one.

IaaS could mean twice the work for IT

In my last blog I wrote about Cloud Management platforms, and how they enable integration of multiple clouds (public and private).

One purpose of this is to drive standardisation of infrastructure. This is the usual drive for standards, strategies, life cycling and consolidation that has been with us for years.

Tech-heads get excited about new stuff like node.js, ruby on rails, Ubuntu, skinless servers etc., but in isolation these technologies provide absolutely no benefit to a company. They cost money to buy, build and support. When these component technologies are combined with application logic and data though, they can add immense value. This value must exceed – by a decent margin – the sunk cost of deployment and support.

IT vendors move between mass standardisation/commoditisation and differentiation – sometimes doing both things at the same time. AWS, GCE, and Azure strive to provide a base server at the cheapest cost – ie. commoditisation – but at the same time offer differentiated, non-standard services like Azure Service Bus and Redshift – to get the customers in (and keep them).

Also, over time enterprises accumulate legacy bits and pieces that are too old, too important or too expensive to replace. There they (dis)gracefully age until something serious happens.

All these drivers work against simplification and standardisation. A good friend I use to work with was asked by the IT Group Manager what he would do if, in his role as IT Infrastructure Manager, he had a blank cheque and infinite time. He said something like trash the whole lot and start again. From scratch. Clean out the “detritus”.

Head In A Cloud (jb912 via Flickr)

If you’re an established enterprise you’ve probably spent the last couple of years trying to understand The Cloud and what it means. The years before that you probably virtualised the hell out of everything on some hypervisor, and before that you tried to get everything on commodity servers. Along the way you migrated many workloads to the latest and greatest, but not everything. You probably still have non-cloud, non-virtualised, non-commodity gear around. Do you really believe all workloads will end up on IaaS?

(If you’re a start-up, it probably makes sense to start in one cloud. As you grow though you may end up getting stuck using their proprietary technology. That may be ok, or not. Ask yourself, could Netflix migrate off AWS, and what cost?)

You have standards for deploying servers in-house (something like Linux or Windows on a hypervisor), you have standard network switch configurations and whatever passes for standards in the storage space.

You don’t want to manage a second (or third or fourth) set of standards for your IaaS provider(s).

Comparing some pretty standard IT infrastructure objects against some AWS objects:

In-house technology AWS technology
VM template AMI
Load balancer ELB
Firewall policy Security Groups

At best they are only packaged differently (VMs vs AMIs) and their guts are pretty similar. At worst, they have different capabilities, configurations, and therefore standards and expertise (load balancers vs ELB).

If you buy the Hybrid cloud direction we’re heading according to Gartner and your own observations then…

It’s two – or more – standards trying to be one, and that’s possibly double the work for IT.

Another argument for Cloud Management Platforms such as RightScale, Scalr and Kumolus? Thoughts?

What is a Cloud Management platform?

The Cloud keeps diversifying. New offerings come on the market each month. IaaS vendors innovate and create new services to help their customers (and if it also locks them in that’s okay too).

That said there is a core set of capabilities everyone looks for in an IaaS cloud. You may want to build an Ubuntu image with a particular number of vCPUs and memory. You don’t really want to concern yourself with the cloud server types that a vendor like Rackspace or AWS provides.

You don’t want to specialise in understanding the API of every cloud vendor when configuring your continuous deployment tools either.

You just want a server, operating system and some software that you can move between clouds. You’d love it if cloud providers agreed on some standards. If only.

Cloud management platforms – like RightScale (Ed: corrected) or Scalr -manage this disconnect.

Most cloud management solutions are aligning their security models, virtual networking and API strategy with AWS. They aim to provide their customers with the ability to migrate workloads between owned and non-owned clouds. They are both open source and proprietary.

Cloud management platforms represent both an immediate necessity for managing complexity and also an opportunity to start building sophisticated IT operations management platforms that allow better planning for the IT function, an ERP for IT if you like.

The following diagram shows where Cloud Management platforms reside in the Cloud stack (as distinct from Cloud platforms).

Cloud Computing ecosystem
It’s important to understand the difference between a Cloud Management platform (managing lack of standards between clouds) and a Cloud platform (turning your hypervisor and other shared resources into a private cloud)

For your cloud management platform to perform its function of integrating with your private cloud it needs to integrate with your internal cloud platform. Most organisations have created their private cloud by taking their existing investment in virtualisation and adding a cloud platform tier.

The expected features of a Cloud Management platform are:

  • Public/Private Cloud integration
  • Manage Compute, Store and Networking consistently.
  • Metering – The ability to track usage and apportion costs.
  • Templates – to support quick provisioning
  • APIs – to enable integration of other business systems such as billing systems and CRM. Integration with configuration management platforms such as Chef and Puppet to describe infrastructure in code.
  • Role-based access – d’uh.

There is a lot of confusion about terminology. This is partly because of the rapidly changing market and also because vendors are developing solutions that overlap different areas. Maybe they are trying to confuse us on purpose! Terms such as Cloud Brokers and Cloud Infrastructure Management are bandied about.

What is your Cloud Management strategy? Do you need one? Or are you picking a single vendor to keep it all simple?

Load more
%d bloggers like this: