Profile cover photo
Profile photo
vKen.Cline does virtual
If it's not virtual, it's not real!
If it's not virtual, it's not real!


Post has attachment
I've been blogging over on WordPress again. Please go check it out at
Add a comment...

Post has attachment
Response to: Cloud Computing and The Rules of Machines in the 21st Century

Oh man, I just ran across an interesting article over on LinkedIn and I just had to post a response.

Interesting article, but I have some questions / comments:

You say: 
"Given the massive power of cloud and quantum computing, the use of robotics, much like the Terminator, will ultimately take over 75% of our daily activities by the year 2025."


"the amount of computation will be so massive that driving applications of the future like robotics will become rather easy to implement in real life. In essence, we will become a robotic world by 2020"

but I see nothing to substantiate that claim (not sure why there's a five year difference there, either). There's a lot of discussion about the increase of network traffic and the enhancement of compute capability, and I assume you're making the case that, because of the exponential improvements in network infrastructure (to support the massive increase in demand) and computational capability, that "robotics will become rather easy to implement in real life".

I happen to agree that robotics will become (more) commonplace than it already is today, but I'm not sure cloud computing is the reason. The usage of robotics has been increasing dramatically over the past hundred years or so, and I see no reason for it to slow down. 

Your next example of the benefit of cloud computing deals with extending our extra-solar system visibility to over 12B light years away ... suggesting that this will give us the ability to "finally be able to see if there is other life outside of our solar system". I'm not sure I follow the logic here. If we can see 12 billion light years away, we're seeing things as they were 12 billion years ago - and we're seeing a tiny sliver of the diorama of the environment that was present.

Next, you go on to reiterate that there will be "massive data and quantum computing in the cloud" and make the assertion that "This is why cloud is becoming the de facto standard of the 21st century for all enterprises and service providers across the planet."

There will be massive improvements in data management and computational capabilities with or without the cloud. And I see no evidence that "cloud is becoming the de facto standard of the 21st century". In fact, enterprises are struggling to fully take advantage of virtualization. Cloud computing is still very much a pipe dream for most enterprise customers that I've dealt with. 

Let's move on to your top 10 list. I actually agree with many of these, but some I have questions about.

1. Security & Availability: Agreed. Particularly on the security part. This is one of the key inhibitors to enterprise customers making the leap into the cloud computing pool. One aspect of security that is frequently overlooked is data sovereignty. Cloud customers must be able to know - and control - where their data lives and who has access to it.

2. Unified Communications: Why is this a #2 priority? When I think of UC, this is what I visualize: - why is this critical to cloud computing? If you mean the adoption of communications standards to enhance cloud service interoperability, then I can see the need - but if it's the wikipedia meaning of UC, I'm confused.

3. Enterprise Applications: Again, why? Enterprise applications (ERP and LOB applications) will eventually make it to the cloud, but they're not what's going to drive the exponential growth. It's all the little "this and that" applications that support the enterprise applications that will do that. When you look at the number of systems used by true "enterprise applications", it's relatively small. Additionally, you have to address priority #1 (Security) before you can even begin thinking about moving enterprise apps to the cloud.

4. Cloud Orchestration: Agreed.

5. Cloud-Based Services: Not exactly sure what you mean here. Everything that lives in the cloud is, by definition, a "service". If you're talking about services such as authentication, reliable messaging, data protection, robust billing, etc. then, yes, they're needed.

6. Data Analytics: Again, why? Data analytics is a workload that the cloud can enable, but why is it necessary for the growth of cloud computing?

7. Converged Services: If you're talking about where "converged services" are effectively the arbitrage and aggregation of services to provide a highly flexible and dynamic service offering to consumers, then I'm right with you.

8. Infrastructure Value: Need clarification on this one.

9. Platform Virtualization: Again, not sure what you mean by "platform". If it's the physical infrastructure, we're well on the way there. What we really need is better orchestration above the hypervisor to enable freedom of choice at they infrastructure layer (choose the hardware & hypervisor that best meets the required SLA). If you're talking about Platform as in PaaS, yes, we need significant enhancements there!

10. Network Virtualization: The current batch of network virtualization products that are out or on the horizon have significant value inside the data center, but they fall short when you exit the data center. Network Virtualization from folks like Nicira (recently acquired by VMware) is all about edge virtualization. This will provide significant benefits within an individual data center - and between well-connected data centers, but not across "the Internet". We're still going to be relying on Cisco, Juniper, Huawei, HP, and others to build the long-haul distribution networks that interconnect the data centers.

There are a few things that I think are missing from your top ten list:

-- Better metering and billing systems. If you can't appropriately track and bill for the resources that are consumed, the cloud will fail.

-- A change in the mindset of enterprise management. Until the CxO is willing to hand over control of their IT resources to a third party, you're not going to see widespread adoption of cloud computing in the enterprise market. This goes hand-in-hand with Securing the cloud. You can't have the change in mindset until security has been proven.

-- An improved cloud management solution. The true value of the cloud is the ability to dynamically assemble services based on the required SLA. This will require a couple of things: 1) a robust, centralized service registry where services can be advertised; 2) an arbitrage/aggregation capability that consumers can utilize to procure a service based on a template/blueprint; and 3) a standardized way of defining the service template/blueprint so that it can be both easily understood by a human and easily consumed by the cloud management solution.

-- An understanding by application owners and developers that, in order to derive the maximum value from the cloud, you HAVE TO REWRITE YOUR APPLICATIONS. Yes, you can simply "P2V2C" (physical to virtual to cloud) an application and it will "work" in the cloud, but that doesn't mean it takes advantage of the cloud features. Applications have to be rearchitected and rewritten to take advantage of things like auto-scaling, fault tolerance, and incremental updates.

Oh well ... Thanks for posting this. It gave me a chance to put some of my thoughts "on paper". I'd like to hear what you think of my comments...
Add a comment...

Post has attachment
Cloud Computing: do you have a clue?

Here's my response to a comment by trevorcsr@ in this thread:

The comment to which I'm replying:

I was hoping to get info on what this Cloud is. I am not a techie just a one finger typing director. First why is it called the cloud - clouds to me means rain, floods, lightning and other disasters but I assume that is not why it is called that?. I want to know why is it good for me, why store stuff up in someone elses system who I assume will charge me a lot of money for and will make it difficult to change to different suppliers if I get annoyed with them. USB hard disks are cheap as backup as well as services like Carbonite who I use to back up all my data. I assume I need some Cloud supplier in my own country in case of war as I don't want it all turned off to bankrupt me and my country. I assume who owns the cloud rules the world of information. What happens if the Cloud company goes bankrupt or can't this happen and am I being paronoid. Sorry as I said I do not understand.

My Response:

As this article points out, many people - including those who should know - don't understand what "cloud" is. As for why it's called cloud, I don't have a real answer for that, but based on what I've seen over the past 30 years in this business, I assume it derives from the practice of using a cloud symbol on architecture diagrams as an abstract representation of "something that just is", like the Internet. It's something that somebody else has control over, someone else worries about, and you simply pay to use it.

Probably the biggest thing you need to understand about "cloud" is that it's not a huge new technology. It's primarily a paradigm shift in how IT services (that's a key are delivered. Traditionally, IT has been paid for using capital funds. Moving to cloud enables you to use operational dollars (or whatever currency) to pay for your IT capabilities. This simple shift enables you to better understand the impact of IT on your business - and isn't that why you use IT in the first place, to enhance your ability to deliver business services to your customers?

Additionally, using cloud computing allows you to focus on the things that are important to your business. If you're not an IT service provider, your core competency is not storage, networking, servers, and application management. You build things. You provide business services. You use IT to support your primary business function. You care about two things:

1. You care about the applications you use. Your business processes are implemented in those applications. The things that differentiate you from your competitors are represented by those business processes.
2. You care about the data that your applications manipulate. Your data represents your products and services. It also represents your customers and the relationship you have with them. 

Using cloud computing allows you to focus on those two things that are important to your business. You let someone else worry about all the "stuff" that happens between your app and your data. You spend your time refining your business processes and their representation in your applications. You also spend your time exploring the data you've captured about your customers so that you can identify new ways to engage them, whether that means new products and services they may find useful or simply a better way to stay in touch with them.

When it comes to the question of why use it, you've hit on some of the key concerns that need to be addressed by your providers. Let's walk through them:

- I want to know why is it good for me, 

I hope I've given you some understanding of why it's good for you above

- why store stuff up in someone elses system who I assume will charge me a lot of money for 

Your data needs to be close to your applications. Your cloud service provider will charge you a fee for this service, you need to make sure you're getting value for your money.

- and will make it difficult to change to different suppliers if I get annoyed with them.

A very valid concern! This should be part of the service level agreement you establish with any cloud vendor. You need an exit strategy not only for your data, but also for your applications. There should be a simple way for you to "take what's yours and go away" whenever you want to

- USB hard disks are cheap as backup as well as services like Carbonite who I use to back up all my data. 

Yes, they're cheap, but USB hard drives are not really useful if you're talking about lots of data. You need to have a robust data protection strategy (more than simple backups) to ensure your data can survive a catastrophic event. I saw a statistic somewhere (sorry, don't have the citation) that over 90% of small business that are hit by a disaster (fire, flood, serious virus infection, etc.) go out of business within two years. This is understandable from the point of view that, most of the time, small businesses don't have a complete data protection plan and the catastrophe means that they've lost access to their customer data (the lifeblood of any business!). Services like Carbonite help, but the problem there is retrieving your data quickly - and those services aren't typically used as enterprise backups

- I assume I need some Cloud supplier in my own country in case of war as I don't want it all turned off to bankrupt me and my country.

Data sovereignty is a critical aspect of cloud computing. In your case, you're worried about political events like war causing you to lose access to your data. In many places there are laws that forbid the storage of many types of data (personally identifying information (PII), financial data, etc.), across geo-political boundaries. These issues must be addressed - and once again, look to your SLA.

- I assume who owns the cloud rules the world of information. What happens if the Cloud company goes bankrupt or can't this happen 

You're not being paranoid at all. Companies go out of business, merge with other companies, get sued, fall under criminal investigation, etc. all the time. You need to be concerned about a lot of different things when it comes to these issues. In the case of going out of business or merging, how does that impact your SLA? What about the privacy terms, etc.? In the case of being sued or criminal proceedings, what happens to your data (see for an example...)

- and am I being paronoid. 

No, you're not being paranoid. The concerns you've raised (and many more) are things you HAVE TO CONSIDER before moving to a cloud-based solution. 

Don't take this as a rant against cloud computing - my job is to get people to move to cloud. I just believe that you need to make the decision to "go cloud" based on an informed business strategy. There are tremendous advantages to moving to the cloud, but you'll realize those advantages ONLY if you're taking the TACTICAL step of moving to cloud for the right STRATEGIC reasons, and only after thorough consideration of the consequences.

Since you're using Carbonite, you've already dipped your toe into the cloudy waters, so it's clear that you see some value in the approach. Is cloud right for the rest of your IT needs? I don't know your specific situation, so I can't say. All I'll say is that you should take the time to evaluate the option and if it's right for you, negotiate an SLA that gives you the rights and capabilities you need at a price you can tolerate (chances are good you shouldn't go with the cheapest solution you can find...)

Hope you found this helpful!
Add a comment...

Which Cloud is Right for You?

Cloud is really no different than any other solution you deploy in your environment. You have to understand the business value of the technology, or you're simply playing with tinker toys.

The first thing people should understand is that "cloud" is much more a paradigm shift than a technological breakthrough. The technologies used to deliver cloud services have, by and large, existed for a long time. Yes, there are "new" twists with things like self-service portals and what-not, but that's just an adaptation of technology we've been using.

Let's start with IaaS. Great technology - it's all about consolidation and standardization. There's some stuff thrown in about user (meaning administrators and developers) enablement and resource utilization metering for cost recovery (which most private organizations don't use), but the major benefit of IaaS is that it allows you to do the same thing you've been doing for the last 10 or 20 years, but do it better. That's why IaaS is relatively simple to deploy ... the challenges are mostly confined to the IT organization because they're going to feel threatened by all the efficiencies that the automation required by cloud computing will deliver. Your IT staff will fear that they're going to lose their jobs.

PaaS is where things begin to get interesting. It's also much more difficult to deploy in a big way into your organization. The impact of PaaS extends well beyond your IT organization. It has a direct and substantial impact on the people who build and maintain your applications (getting closer to the business). The choice of which PaaS solution you deploy IS very important, because it will determine the development stack that your organization uses (although there is absolutely nothing to prevent you from deploying multiple PaaS stacks - i.e. a JBoss stack, a WebSphere stack, a WebLogic stack, a .Net stack, etc.) to meet different business (or political) challenges. By deploying a PaaS stack (or more than one), you enable significant business value to be driven into your application portfolio. You improve the standardization among the various apps (use the same libraries, etc. - which, by the way, your developers will rebel against because it reduces their "freedom of choice") which reduces the learning curve for your users. You'll also relieve your application teams from the burden of having to deal with infrastructure. They'll be able to focus all of their attention where it belongs, on the application. This can result in significantly improved development cycles, which results in faster integration of new capabilities into your applications, which results in you being able to knock the snot out of your competitors.

Finally, there's SaaS. The "holy grail" of cloud computing. You hand over control of the complete technology stack (application, middleware, operating system, and infrastructure) to the cloud service provider (CSP). The CSP could be an internal group or it could be a community or public cloud provider. The most obvious examples of SaaS solutions are email (GMail), sales force automation (, and enterprise resource planning (ERP) (SAP Business ByDesign). In each of these examples, someone else takes care of the technology and you focus on using the application (taking care of business). The downside to SaaS is that you typically have minimal ability to customize the application to meet your business model; therefore, you have to adapt your business model to the application. You can normally change the branding (appearance) of the application fairly easily, but your ability to change how it actually works is limited by how much customization the CSP allows through tenant-specific configuration files.

As you can see, there's a lot to understand when it comes to selecting the cloud solution that's right for you. Chances are, the right answer is a mix of all three:

- use IaaS to further consolidate and standardize your existing environment. If you've not yet virtualized, use this as your opportunity to do that, too.
- use PaaS to support any new application development efforts (including rewrites or significant upgrades to existing applications). Commit to a timeline for redeveloping existing applications onto your PaaS platform so you can benefit from the enhanced consistency and shortened revision turns.
- use SaaS for applications that don't require extensive customization.
That doesn't even address the differences between Public, Private, Community, and Hybrid cloud environments. But that's a story for another day...
Add a comment...

Infrastructure providers are afraid of PaaS.

Have you ever wondered why PaaS hasn't taken off yet? I mean, really! When you look at the value that can be derived from putting a lot of the intelligence of the stack into the cloud abstraction layer, why is it not gaining traction more quickly?

IaaS is all the rage now, and that's a good thing. IaaS enables customers to drive utilization and consolidation much higher than a simple virtualized environment. These improvements are a result of the abstraction of the infrastructure a little further from the user -- BUT -- IaaS is really just a better way of doing the same thing we've been doing for the past 30 years.

With IaaS, the end user is still very concerned with the "server" (even if we call it a "compute instance", it's still basically a server). Still worried about whether their "server" will be restarted in the event that the physical platform that is hosting it fails. Still worried about whether their "server" can be migrated live to another hypervisor instance when there's a maintenance window. Still worried about how to recover in the case of a disaster that takes offline the data center where their compute instance is running.

All this worry is good for the infrastructure providers. It means that Dell, HP, and IBM can still sell physical servers that have expensive fault tolerance features integrated into them. It means that VMware can continue selling HA, DRS, and VMotion (and SRS, and a bunch of other things, too). It means that NetApp, EMC, Hitachi, HP, and IBM can still sell expensive storage solutions that have proprietary replication software to go with it. It means that all the various backup vendors can still sell their backup products that care about "servers". The complexity means that Oracle can still sell their RAC to protect enterprise data.

That's good for the infrastructure providers -- but is it good for you? I don't think so! What would happen if you were to roll your "services" out on a PaaS infrastructure? Well,you would no longer cares about servers, because you no longer interact with servers. you're now interacting with "services".

We're essentially at the next inflection point in IT. The last major inflection point where things changed dramatically was when we moved from physical level I/O (where the application developer had to be concerned with where data lived on the storage medium - had to specify the head/cylinder/track to read or write) to logical level I/O (where the app dev says "give me the third block of data from this file" or "give me the next string of text") and from memory overlays to virtual memory.

PaaS abstracts the infrastructure from the user to the point that the user no longer cares about what the infrastructure is made of. There is an SLA between the cloud consumer and the cloud provider (or, more likely, the cloud broker) that defines the service characteristics such as performance, availability, capacity, etc. It's then up to the cloud service provider to figure out HOW to deliver those SLA characteristics. Let's say that an SLA has the following characteristics:

-- Performance: Process 300 "transaction XXX" per minute with no more than a 20ms response time 98% of the time
-- Availability: 100% service availability
-- DR / COOP:100% service availability

Let's take them one at a time:

-- Performance: Process 300 "transaction XXX" per minute with no more than a 20ms response time 98% of the time

I've intentionally kept this vague - we don't know what "transaction XXX" is, and for our discussion it doesn't really matter. Let's assume that it requires some processing, network traversal, and data access to complete the transaction.

Does the consumer care if we're using Dell, HP, or IBM servers? Nope. All they care about is that their SLA is met. It's up to the service provider to find the best (least cost while providing adequate performance) hardware platform.

Does the consumer care if we're using Cisco, HP, or D-Link switches to support our network? Nope. All they care about is that their SLA is met. It's up to the service provider to find the best (least cost while providing adequate performance) hardware platform.

Does the consumer care if we're using Hitachi, EMC, NetApp, or Drobo storage to host their data? Nope. All they care about is that their SLA is met. It's up to the service provider to find the best (least cost while providing adequate performance) hardware platform.

-- Availability: 100% service availability

In a typical IaaS environment, that 100% service availability requirement would strike fear into the hearts of mere mortals - not so in a PaaS environment. What we're concerned with is the service - not an instance of a web server that's running our application. The service can be widely distributed and have instances running in multiple data centers located in multiple geographies (on different power grids, with diverse network providers, etc.). The PaaS cloud provider is on the hook to ensure that the data associated with the service is highly available and automatically distributed as required...but they get to figure out HOW to do that (Hadoop, Bigtable, MongoDB, MySQL, SQL Azure, Oracle, etc.)

Since the service is geographically distributed and the data is automatically replicated by the PaaS platform, the application developer doesn't have to worry about it - it's just a setting in a configuration file based on the negotiated SLA.

-- DR / COOP:100% service availability

DR and COOP pretty much take care of themselves. Since the service and data are automatically managed by the platform, you don't really have much to do to ensure availability.

So now you're thinking, cool!, but what happens when my transaction volume exceeds my negotiated SLA? Let's say I make snow blowers and there's a prediction that the snow of the century is hitting next week. What do I do? I don't want to have my sales portal slow to a crawl and have all my customers go somewhere else. How do I solve that??

Well, PaaS helps here, too. The PaaS platform exposes a set of APIs that allows customer developed services to be self-aware and to enable dynamic scaling. You simply have the foresight to develop your service in such a way that it monitors the performance metrics exposed by the PaaS platform for certain thresholds. When a threshold is hit (let's say your transaction volume hits 85% of your SLA limit for five consecutive minutes), the service invokes a PaaS API call to automatically move to the next tier of service which gives you additional levels of performance, keeping your customer portal humming along just fine. And the beautiful part of this is that the service can also tell when it's safe to release the extra capacity and drop back down to the lower level SLA tier (bringing the cost back down, too).

So, with all that PaaS goodness, why hasn't the technology taken off? Because the very people who should be bringing it to you are afraid of it! They're afraid that it will commoditize their products and services. The large systems integrators are beginning to open their eyes, but even they are dragging their feet.

Yes, there are some issues with standardization in PaaS. Once you select a platform, it's going to be a little challenging to move to another in the future, and that does give pause. The standards will come, but can you afford to wait? If you are kicking off a development effort, shouldn't you at least give PaaS serious consideration? Why not build a small product using PaaS, just so you can begin to understand the benefits that are available?

In the meantime, continue moving your legacy systems to an IaaS solution. You're still going to gain significant value from the enhanced consolidation and utilization rates - plus, you're going to get your users a little more comfortable with the idea that someone else is taking care of the underlying infrastructure and that they don't have to be able to physically see the hardware on which their compute instance is running.

Just don't be like the infrastructure providers. Don't be afraid of PaaS. There is a lot of value to be found in that model. And just think...once you've built your service on a PaaS platform, you can turn around and resell the service using a SaaS model with you as the service provider!

Add a comment...
Wait while more posts are being loaded