Category Archives: marketing

Cloud infrastructure Economics: Cogs and operating costs

Perhaps the most important benefit of adopting cloud services (either from a public provider or internally from your organization) is that their cost can be quantified and attributed to organizational entities. If a cloud service cannot be metered and measured, then it should not be called a cloud service right?

So, whenever you need to purchase a cloud service or when you are called to develop one, you are presented with a service catalog and assorted pricelists, from where you can budget, plan and compare services. Understanding how the pricing has been formulated is not part of your business since you are on the consumer side. However, you should care: You need to get what you pay for. There must be a very good reason for a very expensive or a very cheap cloud service.

In the past, we have developed a few cloud services utilizing own resources and third party services. Each and every time, determining whether launching the service commercially would be a sound practice depended on two factors:

  • Would customers pay for the service? If yes, at what price?
  • If a similar service already was on the market, where would our competitors stand?
  • What is the operating cost of the service?

Answering the first two questions is straightforward: Visit a good number of trusted and loyal customers, talk to them, investigate competition. That’s a marketing and sales mini project. But answering the last question can be a hard thing to do.

Let us share some insight on the operating costs and cost-of-goods for a cloud service and in particular, infrastructure as a service (IaaS). Whether you already run IaaS for your organization or your customers, you are in one of the following states:

  1. Planning to launch IaaS
  2. Already running your datacenter

State (1) is where you have not yet invested anything. You need to work on implementation and operational scenarios (build or buy? Hire or rent?) and do a good part of marketing plans. State (2) is where you have already invested, you have people, processes and technology in place and are delivering services to your internal or external customers. In state (1) you need to develop a cost model, in state (2) you need to calculate your costs and discover your real operating cost.

In both cases, the first thing you need to do before you move on with cost calculation is to guesstimate (state 1) or calculate (state 2) the footprint of your investment and delivered services. From our experience, the following parameters are what you should absolutely take into account in order to properly find out how much your IaaS really costs.

Financial parameters (real money)

  • EPC: Electrical power and hosting cost. How much do (or would) you pay for electricity and hosting. This can be found from your electricity bill, your datacenter provider monthly invoice or from your financial controller (just make sure you ask them the right questions, unless you want to get billed with the entire company overhead costs). EPC is proportional to your infrastructure footprint (ie number of cabinets and hardware).
  • DCOPS: Payroll for the operations team. You need to calculate the total human resource costs here for the team that will operate IaaS services. You may include here also marketing & sales overhead costs.
  • CALCLIC: Software licensing and support costs for IaaS entire computing infrastructure layer. These are software costs associated with the infrastructure (eg, hypervisor licenses), not license costs for delivered services, eg Microsoft SPLA costs.
  • STORLIC: Software licensing and support costs for your entire storage infrastructure. Include here in their entirety also data backup software costs.
  • SERVER: Cost of a single computing server. It’s good to standardize on a particular server model (eg 2-way or 4-way, rackmount or blade). Here you should include the cost of a computing server, complete with processors but without RAM. RAM to CPU ratio is a resource that is adjusted according to your expected workloads and plays a substantial role in cost calculation. If you plan to use blade servers, you should factor here the blade chassis as well.
  • MEMORY: Average cost of 1 GB or RAM.
  • STORINFRA: Cost of your storage infrastructure, as is, or the storage infrastructure you plan to purchase. Storage costs are not that easy to calculate as a factor of 1 disk GB units, since you have to take into account SAN, backup infrastructure, array controllers, disk enclosures and single disks. Of course we assume you utilize a centralized storage infrastructure, pooled to your entire computing farm.
  • NETINFRA: Cost of data network. As above, include here datacenter LAN, load balancers, routers, even cabling.
  • NETSUPP: Cost of network support (monthly). Include here software licensing, antivirus subscriptions and datacenter network costs.

Operational parameters (Facts and figures)

  • RUAmount of available rack units in your datacenter. This is the RU number you can use to install equipment (protected with UPS, with dual power feeds etc).
  • RU_STOR: Rack units occupied by storage systems
  • RU_CALC: Rack units occupied by computing infrastructure (hypervisors)
  • RU_NET: Rack units occupied by network infrastructure
  • SRV: Virtual machines (already running or how many you plan to have within the next quarter)
  • INTRST: Interest rate (cost of money): Monthly interest rate of credit lines/business loans
  • TOTALMEM: Total amount of virtual memory your SRV occupy
  • TOTALSTOR: Total amount of virtual storage your SRV occupy
  • SRVRAM: Amount of physical memory for each physical server. This is the amount of RAM you install in each computing server. It is one of the most important factors, since it depends on your average workload. A rule of thumb is that for generic workloads, a hardware CPU thread can sustain up to 6 virtual computing cores (vcpu). For each vcpu, you need 4 GB of virtual RAM. So, for a 2-socket, 6-core server you need 2 (sockets) x 6 (cores) x 6 (vcpu) x 4 (GB RAM) = 288 GB RAM. For a 4-way, 8-core server beast with memory intensive workloads (say 8 GB per vcpu) you need 4 x 8 x 6 x 8 = 1536 GB RAM (1.5 TB).
  • MEMOVERPROV: Memory overprovisioning for virtual workloads. A factor that needs tuning from experience. If you plan conservatively, use a 1:1 overprovisioning factor (1 GB of physical RAM to 1 GB of virtual RAM). If you are more confident and plan to save costs, you can calculate an overprovisioning factor of up to 1.3. Do this if you trust your hypervisor technology and have homogenous workloads on your servers (for example, all-Windows ecosystem) so that your hypervisor can take advantage of copy-on-write algorithms and save physical memory.
  • AMORT: Amortization of your infrastructure. This is a logistics & accounting term, but here we mainly use this to calculate the lifespan of our infrastructure. It is expressed in months. A good value is 36 to 60 months (3 to 5 years), depending on your hardware warranty and support terms from your vendor.

If you can figure out the above factors, you can proceed with calculating your operating IaaS costs. Keep reading here!

Over The Top: Too high to reach?

Recently, Facebook got WhatsApp (a mobile multichannel messaging startup) for $19B. It’s still too early to comprehend the rationale of this move: Buying market share? A bubble effect? An ingenious strategy move that aims squarely at service providers? A stupid buyout that will sink FB stock? Time will tell.

However, we can draw some conclusions on what this means for telco service providers. Over the top services (as they usually call the services they cannot comprehend, and cannibalize their market share) have value. And it’s a train they have to catch. Let me tell a story here:

Some time ago, while working for a small systems integrator, we had been setting up a public IaaS cloud provider for the lcal market. The first approach, based on the free Cloudstack edition was a breeze to work with, very very cheap and quite reliable. The number of customers we attracted was… two. A couple of months later, we revisited our strategy – this time, the platform was based on VMware vCloud directory (the very first deployment in the regional market), targeting mostly enterprise customers (and our own customers as well). Things moved a bit better, slowly gaining sales traction. However, this was not enough. A plain IaaS offering would only sell as fast as customers would face the dilemma “buy or rent” and opted for renting infrastructure.

The way forward was to bundle applications with our cloud. We turned to software vendors, hoping to deliver preconfigured cloud servers bundled with software targeting small and medium businesses, with a SaaS licensing scheme. A good move, don’t you think? Guaranteed SLA 99,99%, with preinstalled popular CRM & ERP apps, licensed as a service, no upfront costs, no commitment. Customers would flock to our cloud. Eventually however, they did not. The problem was the total miss of customer addressable market.

Would you like fries with that?

Would you like fries with that?

Let me explain a few things: Building a cloud does not mean that it will sell by itself. We were a small integrator with a cloud service. Our customers were mostly medium enterprises buying services and infrastructure from us. We managed to upsell IaaS to these customers and attract a few new ones. However, no matter how attractive a SaaS offering would be, we had to address a market we did not have any access to. And that’s why we failed.

What does this have to do with telcos and OTT services? A lot. Telcos sell data & voice; they have been doing that forever. On top of their data services lives the entire IaaS, PaaS, SaaS, *aaS ecosystem. The revenue telcos see from the immense value of OTT services is the data rate, nothing more. They don’t capitalize on this market, even though:

  • They own the platform and medium
  • OTT services customers are the same customers they serve,

thigns we lacked when we launched our IaaS and SaaS cloud services. It seems that OTT services are at a cloud reach, don’t they? Every telco can setup an IaaS platform, add some sauce on top (applications, that is) and address their own customer base. We are not referring to telcos-gone-cloud (Verizon/Terremark), we are talking about service portfolios that address a very large part of any telco customer base.

My guess is that all it takes are good synergies here and exploitation of local markets: Upsell services to existing customer by letting other vendors cross-sell their products and services. There are lots of moving parts here, the most important challenge being to build an efficient ecosystem, reach & upsell to own subscribers and produce value to the end consumer. One needs to step into customer shoes, tick the right boxes from a desired service list, find the right partners and deliver these services from established sales channels.

 

Of cloud and factories

The most common metaphor for cloud computing is that it’s like your electric power company. Flick the switch on, log in to your cloud service, pay for what you use, log out, flick the switch off, go to sleep. Well, it’s a bit more complicated that that.

Power companies offer a single product: Electric Power. How many variations are there? Compare them to the myriad cloud offerings: Infrastructure as a service (virtual machines, Windows or Linux), Storage as a service (online, backup, archiving), Software (everything). To me, it looks more like manufacturing and selaling cars. And the cloud business has striking similarities to car manufacturing: Just assume that every car manufactured and sold is a month of a cloud service – any kind cloud service. What are the analogies?

  1. The infrastructure that powers a cloud service is like a car factory. There is an assembly line, pumping out a particular car model/cloud service. In both cases, the product is as good as the materials it’s made of and the quality of the manufacturing process. Also, the pricing catalog varies accordingly.
  2. Cars shipped out of the factory need an extended and reliable transport network, like rail, ports, RORO ships and so on. The same is true with cloud services: Since they are delivered over the Internet, cloud providers need multihoming (peering with at least two Tier-1 or Tier-2 providers), low latency and high bandwidth.
  3. Economies of scale and just in time production: The more cars you build and sell, the cheaper they are. Same thing with cloud services (Amazon Web Services). Also, adding more capacity as you grow is the only sustainable model for cloud providers – the analogy in the car industry is just in time production.
  4. Go to market: Building a cloud service is one thing, selling it is another. All car brands have an extensive network of resellers and dealers, cloud service providers rely also on partners and heavy Internet advertising and market awareness to bring in the sales volume to sustain their business. And volume is key to cloud services, just as it is in the car industry.
  5. Product qualities: Cars come in all sizes, shapes, colours, equipment. The same applies to cloud services. They all look alike (for example, all cloud service providers offer Windows servers), they do the same job, but what really matters is performance, capacity and reliability. What qualities would you look for if you were on the market for a new car?
  6. Common technology: Have you opened the hood of an Audi, Skoda, VW and Seat? The mechanics are the same, but the badges are different. Moreover, three technologies (soon to be four) power all cars on the globe: Gasoline, Diesel, hybrid (and electric in a few years from now). Guess what, it’s the same with cloud computing. There are only a handful of hypervisors and automation platforms that power most cloud service providers, yet, every provider has their own look and feel.

The perfect analogy would be the factory this gentleman used to run:

Want to do cloud? You need to sell it, stupid

From a technology standpoint, cloud computing is the convergence of many beautiful things: Think SOA, governance, virtualization, The Web, data management and process automation. All running inside a lean machine, making the delivery of computing as easy as shopping in a mall.

However, building a cloud is one thing and making money out of it is another story. It’s not only about the infrastructure, is a lot more.

A successful and complete cloud stack has lots of moving parts, and most of them are software, not servers, storage and switches. It’s about your network provider and datacenter SLA, your ISO20000/270001 compliance, a decent chargeback and billing system, the applications or vApp templates you build and  a lot more stuff. It’s complex, with many stakeholders and at the end of the day, it’s not cheap to build. It resembles the eTOM model with a twist of ITIL. But if you manage to sell it, it’s a money making machine – either by slashing operating costs more than half or by generating revenue from your customers.

Now, who are you and to whom should you sell?

  • You are an enterprise or a large organization: If you have less than a  hundred internal users, forget it, otherwise, build your own private cloud. The benefits you will get from knowing who owns that IT resource, why, for how long and charging back the resource to the end user are too good to ignore and stick to a break and fix IT mentality.
  • You are a managed service provider/systems integrator: Building a public cloud is something you can do well; you know the technology and have the building blocks. But, to whom would you sell it? Most likely, you are already consuming private cloud services internally; finding external customers for public cloud services is easy, right? Wrong. Your business organization is set up to deliver vertical specialized services, but cannot do volume selling: Successful public clouds are built on customer volume and this is something you do not have (and do not know how to build up). What you can do is to go to your customers and sell your existing services porfolio in a cloudified form: Disaster recovery as a service and secure workload bursting are services you can deliver and successfuly market.
  • You are in the telco/service provider/web hosting business. Excellent, you know pretty well how to deal with lots and lots of customers. You know very well how to sell services in neat packaging. What you don’t know is how to build cloud services – this is the reason that Verizon, Sprint and others have long ago swallowed datacenter builders like Terremark and Savvis. However, public clouds fit very well in a service provider business model: Customer volume is there, charging/billing/provisioning are there, governance and compliance are there, datacenters and networking are in place. The technology stack bits and pieces are missing but they are easy to shop. What are the speedbumps? Telco strategists have known for decades how to market broadband, datapipes and voice. What they do not understand 100% is how to sell software, and cloud computing is, well, software.


 

 

 

Adding value to SaaS

Software as a service is an entirely different animal from IaaS or PaaS. Implementing the latter two can be done (almost) with platforms available off the shelf and engaging a few consultants: Grab your favorite cloud automation platform (pick any: Eucalyptus, [Elastic|Open|Cloud]stack, Applogic, Abiquo, even HP SCA, throw in volume servers and storage, host on a reliable DC and you are good to go).

On the other hand, SaaS is something you have to:

  1. Conceive. IaaS and PaaS are self explanatory (infrastructure and platform: Virtual computing and database/application engine/analytics for rent); SaaS is… everything: from cloud storage to CRM for MDs.
  2. Implement: SaaS is not sold in shops. You have to develop code. This means, finding talented and intelligent humans to write code, and keep them with you throughout the project lifecycle.
  3. Market: Finding the right market for your SaaS is equally important to building it. SaaS is a service; services are tailored for customers and come in different sizes, colours, flavors. One SaaS to rule them all does not work.
  4. Sell: Will you go retail and address directly end customers? Advertising and social media is the road to go. Wholesale? Strike a good revenue sharing deal with somebody that already has customers within your target group, say, a datacenter provider or web hosting.
  5. Add some value to your SaaS. Cloudifying a desktop application brings little value to your SaaS product: It’s as good as running it on the desktop; the sole added value is ubiquitous access over the web. Want some real value? Eliminate the need to do backups. Integrate with conventional desktop software. Do auto-sync. Offer break-away capability (take your app and data and host somewhere else).
Let’s take two hypothetical examples: Cloud storage and CRM for doctors.
Cloud storage is a good offering for customers seeking a secure repository, accessible from everywhere. Let’s consider two approaches:
  • High end branded storage array with FC and SSD disks
  • 5-minute snapshots, continuous data protection
  • FTP and HTTP interface
  • Disk encryption
  • Secure deletion
The second approach would be:
  • WebDAV interface
  • Data retention
  • Daily replication
  • Auto sync with customer endpoints
  • Integrated content search

What’s wrong with the first approach? It is typical of the IT mindset: Offer enterprise IT features, like OLTP/OLAP-capable storage to the cloud. Potential customers? Enterprises that need to utilize high-powered data storage. Well, if you are an enterprise, most likely you’d rather keep your OLTP/OLAP workloads in house, wouldn’t you? Why bother?

The second approach offers services that are not delivered from your enterprise IT machinery. It’s added value to a cloud storage service and at the end of the day, they are deemed too expensive or complicated to implement in house. Potential customers? Enterprises that have not implemented these services but would seriously consider renting them.

Let’s consider now a cloud CRM for doctors. What would be some value added features for private MDs, apart from a database with customer names and appointment scheduling? I can think of a few:

  • Brief medical history of patient delivered to the doctor’s smartphone/pad. Can save lives.
  • List of prescribed medicines with direct links to medicare/manufacturer site. Patients can forget or mix up their prescribed drugs; computers never forget.
  • Videochat with patient.
  • Patient residence on Google maps and directions how to get there

Will your cloud make money?

What comes first, the horse or the carriage? If you want to start your cloud business, do you need first to come up with a solid revenue model (how can you make money out of it) and then figure out how to implement it, or first you build it with what you know and then figure out a way to make money?

Actually, the most successful cloud companies did not follow either path. Google started as a search engine and then figured out a smart way to sell advertising to the millions eyballs skimming the text results. Amazon spun off IaaS from their main business, beating others on pricing options and rich technical choices. LinkedIn capitalized the business social network. Salesforce started from plain sales automation, now offers a full portfolio of business software. What do all of these have in common?

First, their revenue model constantly evolved down the road. Some started as spinoffs from an entirely different line of business, others offered free web services or subscription-based, yet, all of them changed their revenue models and adjusted their pricing strategies almost every quarter.

Second, they own their software and infrastructure. Instead of shopping around for bits of software, they control their code (by paying good money to talented humans to write, maintaind and update software) and their infrastructure: They own their datacenters. Large ones, with huge economies of scale.

Third, they control their supply chain and rely on partners and affiliates either for pure retail business or for added value services. If you are using their services, you pay them directly. If their services go down, you go after them directly. They do not maintain channel networks to resell their solutions, since the Internet is omnipresent and their portals one click away from your home page, so, why bother setting up a reseller or distribution network?

Fourth, and most important: They control their revenue model. Google capitalizes on hundreds of millions people using their free services. Amazon is perfectly aware that their IaaS services do not address their direct customers, but the customers of their customers and have adapted their pricing and services accordingly. LinkedIn offers a rich business communication platform where online recruiters and businesses can directly interact with their members. SalesForce constantly adapts and add new services that their existing customers can readily use.

The question is:  Can I do the same without biting the bullet and instead get bits and pieces off the shelf? For example, get some branded hardware with 24×7 support, rent some rack space, run Azure/VMware/Citrix/RH, get a decent cloud management platform, strike a few deals with cloudified software vendors and bring channel partners to do the reselling and distribution of my services?

Will this work? No.

First, you do not control your revenue model. You depend on a channel to resell your services, which means that you depend on your partner’s revenue model. In turn, you are also a reseller of somebody else services and products: You resell a hosted CRM or Azure/VMware/RedHat virtual servers and software platforms. And finally, you do not own your infrastructure, which means that you cannot control running costs of support and hosting.

Are these a bad thing? Yes.

In terms of money: Channel partner = $$ (their markup). Branded servers = $$ (acquisition & support). Renting rack space = $$. Azure, VMware and friends = $$ (licensing and support).

In terms of agility: Introducing new features and services is not a single step process: From tuning your heterogeneous software and hardware stack up to communicating the new services to your channel partners weeks, if months, pass, without revenue flowing in.

And then in terms of customer experience:  Figure out what’s wrong when something breaks (is it the application? Is it the virtual server? Is it the hardware?), call the cavalry (contact the appropriate vendor) and have them fix it. During all this time of this fascinating game of fault tracing and bug whacking, your customers’ business is directly affected: It’s down.

The car paradigm

Have you ever come across a situation where you have to explain something in 3 minutes to an audience which seems to have no clue what you are talking about? Use the car metaphor. It works.

Cars are ubiquitous. We all use them, either driving them or being simple passengers. We know their shape, size, their brands, the engine noise – some even name their cars. They are big or small, fast, slow, mean, cute. Making a parallelism of a solution or product with cars is easier, but you have to pick the right attributes. An example is systems and network management and why you need them. Try to drive your car without adjusted mirrors and no dashboard: You don’t know if there are other cars in your rear corners, so you cannot change lane easily or turn. You don’t know how fast you are going, neither if your engine runs too hot. You don’t know how much gas you have in your tank. Pretty awkward, right? Well, it’s the same with running an IT and network  infrastructure without some kind of OSS or network management framework: As long as you drive straight and with a constant speed, everything is fine, yet, at some time, something will break down, a service will start spinning, storage pools will degrade or fill up, Will you be aware of these events before they occur and phones start ringing?