MemorableURL.com

Are all fingers thumbs? SaaS vs. Cloud as a delivery model.

I was reading a great Gartner article today about delivery of IT operations management tools and it has some very interesting observations related to the perception of SaaS vs. the Cloud. The question that got my attention related to whether SaaS and Cloud were the same thing. Of the respondents almost exactly one third selected yes, one third selected no and the remaining third went for “sometimes”. It’s rare that you see quite such an even distribution in any survey and it got me to wondering why it’s so ambiguous. The answer, it turns out, is actually found within the same article…

The definition is in the eye of the beholder

In my mind it is fairly clear – they are not the same. Let’s look at some examples:

• Both: Salesforce.com is software delivered as a service in the cloud. It has everything that you’d expect from a combination of these two things: software, pay as you go, self-service, elasticity, etc.
• Cloud only: Amazon EC2 is delivered via the cloud with the expected pay as you go, self-service, etc. but it’s not software…OK, it is software but it is platform/mid-tier software as opposed to consumer application software
• SaaS only: EMC’s Documentum OnDemand is a single tenant, hosted application managed as if it was a cloud solution but it doesn’t have those features generally associated with the cloud like multi-tenancy, self-service, etc.

Seems fairly straightforward when you see it written down doesn’t it? Except EMC touts OnDemand as a cloud solution and no one bats an eyelid, in fact as far as their customers are concerned they are getting Documentum “in the cloud”. Equally, consider that many people will deploy a standard instance of an EC2 environment and use the included middle tier applications, (e.g. the app servers and databases). To them EC2 is providing both SaaS and the Cloud.

So where is the confusion? It’s the same old chestnut that technologists fall fowl of consistently. From where we are standing the difference is startlingly obvious but from where the customer is standing the semantics are meaningless. I could argue until I am blue in the face that a single tenant deployment is neither SaaS nor is it Cloud, it is simply a hosted system but does a customer care about the subtleties? Typically the customer cares (or should care) only about one thing – meeting the terms of the service level agreement. They want a system off premise for very specific reasons and none of them should relate to the underlying technology details.

Let me illustrate this by defining the three models from the perspective of the service provider vs. the consumer of the service.

Term	Technologists say…	Consumers say…
Cloud	Multitenant, virtualized, self-service application with common, elastic infrastructure, pay as you go.	Cheap and cheerful
SaaS	Semi-standardized deployment of commercial application with partially shared services and centralized management and control.	Easy and customizable
Hosted	Single tenant, bespoke deployment of customized solution with dedicated services, storage, etc.	It’s mine, all mine

Seems like we are a little too focused on the technical details and missing the point…who cares? As the infrastructure and service providers we get all uptight about the semantics and we forget that the customer’s view is very different. We might was well advertise like this:

When the customer really wants to hear…

What should we do?

It is not breaking news that the reason that Apple have been so successful is not only that they listen to their consumers but that they present things in a way that grabs consumers’ attention. When Microsoft release a new hardware product they open with the specs of the machine…when Apple release a new product that hold it up and effectively say “ooh, ooh, it’s shiny and you want one” then they take your money, give you the product and THEN you work out what it is and how to use it.

I talk about the Mainframe as a platform for the Cloud (or SaaS/hosting if you want) but I need to remember to always return to the value that the ultimate end user of the system is actually interested in – it’s really, really reliable, it’s cheap and it’s fast. Odd though isn’t it? This description makes the mainframe sound a lot like a commercial for a Toyota Camry which is just not the vehicle you might compare a mainframe to normally.

So all thumbs are fingers but not all fingers are thumbs which adds zero clarity to this article but I just watched that episode of the Big Bang Theory and it seemed to resonate!

Session Abstract - Lessons learned from addressing the inevitable.

I was asked to submit a topic for a cloud-related conference, I'm thinking of "Lessons learned when moving enterprise software from a conventional deployment model to a cloud-based model." Obviously I'll need a snappier title like "What were we thinking?", "Please Lord make it stop." or maybe “Lessons learned from addressing the inevitable.”

Specifically the session will relate to companies selling enterprise software and are going to start offering their solutions in the cloud or service providers looking to sell 3^rd party enterprise applications in the cloud.

I’ve attended these “lessons learned” sessions in the past and prefer the ones that basically list all of the things that you need to watch out for with general lessons learned. In the world of enterprise software knowing the specifics of one company’s experiences is not always germane to other deployments. To that end I’m going to focus on the actual issues and some hints on how to avoid them. Here's my outline...I'm going to blog on each of these over time to help me to solidly my thoughts. I’ll add to this as I go.

Internal issues to address

I'm starting with “internal issues” because IMHO these are far more difficult to deal with than the technical ones.

• How will you compensate the field when you move to a SaaS model?
  • Any subscription-based pricing looks less attractive in the short-term to the people being paid on revenue.
• Re-educating the field on what a move to SaaS means.
  • Don’t underestimate the effort in undoing all of the “big sale” indoctrination that you’ve instilled in the team.
• Deciding which customers/use cases to go after first.
  • If you elect to go “cloud” not “managed service” then you are going to have to apply restrictions on how your customers use the systems. How will that change your GTM model?
• Deciding when/if you'll stop supporting new conventional deployments and existing conventional deployments.
  • Will you continue to sell a non-cloud version of your software? This is not a trivial question, the timing is especially important.

Technical issues to address

I'm intentionally not addressing HOW to get your non-multi-tenant solution into the cloud, that's the topic of many other sessions. I'm focusing on the other issues that you'll need to address after you've done it.

• Migration offering for existing customers.
  • Don’t just think about data, think about processes, policies, monitoring, integrations, etc.
• Convincing your customers that your offering is secure, performs well, will integrate into their existing systems, etc.
  • “Confidence”…your customers know how enterprise software deploys today. They may not like it but they understand it. You need to convince them that a move to “less hassle but less control” is going to be a benefit.
• Service levels
  • Customers will have preconceived ideas of what your service level objectives are. Up-time, high availability, data replication, location of primary and backup data centers, performance, etc. These cause work for legal, the deployment teams, the ops teams, pre-sales, etc.

Things you never thought of

• Contracts...you might have enterprise agreements for software and services today but I'll bet that they will not work for your cloud customers.
  • Don't underestimate this one; it is where all of the other issues come to the surface. Why? Because not someone needs to sign a piece of paper that says that what you are offering them will meet all of their needs…and that’s scary.
• Managing the transition from conventional to enterprise.
  • How are you going to manage the transition to a cloud service provider? Will you go "all in" and rebrand yourself as cloud supplier (alienating your current customers), be low key with your cloud offerings at first (letting your competition take the lead), will you start a new organization for the cloud solutions (creating internal strife and completion)?
• Delineation of responsibilities - who exactly is responsible for what?
  • You will have a contract to supply a service to your customers but there will always be a grey area. You will run the servers and they will consume the service. Easy, yes? But who will create users, who will do end-to-end performance optimization, who will monitor usage, etc.?
• Selling…internally.
  • There will be resistance to a move to the cloud and not just from the customer base and the field. You might get push back from engineering, senior management, internal operations, etc. You need to spend an equal amount of time getting buy-in internally as you do selling to your customer base – at first that is.

Objections that you need to be able to handle

• Security. This is the number one objection that you need to be able to answer. How can I be sure that my content is protected and will not be lost?
  • One specific question - who has access to the data and where will it physically reside? This might relate to compliance as some data needs specific levels of protection, (e.g. UK health data, German tax data.) but in many cases this is actually just “justifiable paranoia”.
• Latency. You are moving a service out of a customer’s data center and they’ll want to know how that will affect performance. In my experience it is actually often better – latency is a minor tax on performance in comparison to the gains in having a well-managed, optimized service running on a major piece of hardware.
• Enterprise connectivity. If the customer has systems inside their firewall that need to connect into your service – public, private or hybrid then they will need to know how that’s going to work…and how well.
• Customization support. If the customer has “special” needs that involve making a change to their base environment then how will you handle this, if you will even allow it. 

Cloud Computing Business Considerations - The single most important document

We are doing some advanced training for the field this week on how to sell ECM in the cloud now that all of the pieces are in place and customers are using it for real. At least that's how we advertised it internally: "advanced training". As I was sitting in the United lounge in DC waiting for my 6 hour delayed flight to Atlanta I got to thinking about the "advanced" part of that.

It seems that 12 months ago when we were embarking on this crazy plan I had this huge list of potential issues. I started to blog about them to bring clarity to the tasks. I was considering pricing, services, deployment models, geo-location-related issues, delineation of responsibilities, etc. 

Now I struggle to remember what exactly the mystery was. We just educated a room full of experienced account managers with all of the things that they need to understand it in 2 hours. In fact, the only issue that seems to cause anyone any heartburn relates to reconciling the contract for the cloud services to the other contracts that customers have. The rest of it seems so straightforward now.

So what made it simple all of a sudden? IMHO, it was the completion of one document –  the services brief. This is a document that explains all of the things included in the cloud offering. The components of the system, security considerations, connectivity into existing systems, the initial build information, roles and responsibilities, how upgrades are handled, details of HA and DR, support management, service level objectives, etc., etc.

All of the technical issues turned out to be things that we needed to solve but that our customers don't need to worry about. Once we created implemented everything in the services brief everything just fell into place.

• Return on Investment: we use the services brief to show the customer what they are getting for their money. They use this to compare the cloud costs to their internal costs.
• Contracts: we attach the services brief to the contract to show what is included.
• Security: the services brief shows all of the components related to security, DR/HA, audit, reporting, etc.
• Delineation of tasks: if it's not in the services brief then it's your problem Mr. Customer.
• SLOs (Service Level Objectives) : most of this is covered in the services brief although the contract forms a key part of the SLO because it is an official agreement.
• License ownership: ditto...you get the idea.

It's not the only document that you'll need, it does not cover everything…the system setup, pricing, terms of sale, etc. but once you have it everything else falls into place pretty quickly.

This document also serves as an important reminder that as a customer you don't need to worry about the "how", just the "what" you get. Armed with the services brief, a contract and a price you are good to go. Maybe there's some minor network config work, some setup or migration but basically the services brief is the core to your agreement with the provider.

Now I'm going to work out how to index my articles without the god awful table of complexity that I used back when this all seemed complicated. My next article..."Why on earth would anyone implement ECM on premise for a new deployment?" ;-)

Cloud Computing Business Considerations - Pricing Models

Some people think that the difference between "a cloud deployment" and "a hosted service" is how the payment plan is structured. They imagine that if you have no capital outlay and just pay a SaaS usage-based monthly fee then you must be using the cloud. If only the definition of a cloud solution were that simple, there's a lot more to it than that including any definition that suits a vendor wanting to milk the current gravy-train.

This SaaS pricing seems like a nice model but it is pretty much the same model as leasing or renting a car. When you buy a car *you* are financing the capital cost of the car and you own it outright. When you lease or even rent a car someone else is financing the car and you own nothing at the end of the term, also you are eventually covering the cost of the third party financing it.

In many cases this is a great model but for enterprise software running in the cloud you might want to consider alternative models before getting out your credit card.

First let's assume that the software you are looking for is available to purchase in a conventional (non-cloud) model. Some systems are only available as SaaS offerings so you have what folks in the UK call "Hobson's Choice". If you can purchase the software licenses then there might be advantages to you buying the software outright and paying a lower fee just for the cloud hosting piece. Why?

• You may already own licenses to the software so why pay twice? Of you've already paid for the software then it might be more cost effective not to take SaaS pricing.
• It might be less expensive over the life of the project if you purchase the software outright rather than allowing the cloud provider to finance it.
• What if you want a hybrid deployment where you have some systems in the cloud and some on-premise? You'll need regular licenses for the latter anyway. This is a business case that I am seeing more frequently than I'd expected. It is driven by legacy deployments, schedule issues, geographic constraints, regulatory issues, etc. 
• What if you decide to back out out cloud and want to move the entire system on-premise? This is low probability and might just be addressable "if and when".
• You might prefer Capital Expenses over Operating Expenses, (really...some US federal agencies have CapEx budget but don't have OpEx!).

Conclusion

Sometimes there's no option but to purchase a solution with SaaS-pricing. In the future the SaaS model might be ubiquitous but today as we transition to Cloud delivery you might want to give this some thought to the options before jumping in.

Cloud Computing Business Considerations - Dealing with Data Center Placement

In this article I will consider where geographically you might want to host your cloud-based systems. The world’s a big place and for many organizations deciding where to host systems is a complex issue - with or without the cloud. For commercial convenience organizations tend to break the world down into three areas – the Americas, EMEA and APJ; I'll use that same model.

Coverage in the Americas

It is fair to assume that if you placed a data center into the central USA then you’d be able to offer decent coverage to 80% of the commercial opportunities in the Americas region. You would not be geographically central but you would be close to the majority of the opportunities in the region; that’s the reality of the distribution of commerce across the landmass. Place 2 or 3 datacenters throughout the region and you will have pretty much the entire area sown up.

From a compliance perspective many customers in Canada and Mexico are willing to tolerate a US-based data center when their local regulations allow.

Coverage in EMEA

For EMEA you have a similar model; place a data center in mainland Europe and you can probably offer your service to the majority of the region’s commercial opportunities. Again, distribute 2 or 3 data centers in EMEA and for sure you have cornered the market. I get that Johannesburg is a good 6,000 miles from Helsinki but commercially the key opportunities are centralized around mainland Europe. The EU has also passed a number of regulations to manage the distribution of content between countries. 

Coverage in APJ

APJ brings its own set of challenges. Like EMEA and the Americas it covers a vast area from the southern hemisphere to the north. However unlike in the the other regions, in APJ the distribution of commerce is more even. So placing data centers in 2 or 3 locations does not give you the 80/20 coverage that you might see in the other regions.

More of an issue than the geographical distribution of commercial opportunities is the lack of unity between the countries. In the European Union there are laws that allow for the sharing of protected data between member countries, in many cases this might allow for a centrally located data center to host systems used across many countries. In APJ the story is very different:. A company based in one country may legitimately refuse to have their data stored in any neighboring country because they want to have certainty around who has access to the data and they cannot control another country’s laws/administration.

I started writing this article on a flight back from Hong Kong. Hong Kong is part of China albeit they call it a SAR (Separately Administered Region). I asked whether the customers based in Hong Kong would use a China-based data center. The answer was “absolutely not”. I asked whether Taiwanese customers would use one in a China or Hong Kong – “nope”. Japan using Singapore? India using Australia? Australia using New Zealand? No to all… The only concession that I heard was that some of the customers based in southern China regions might consider using a Hong Kong-based data center but not those based in the northern regions ;-)

Similar issues also exist in EMEA and the Americas with specific content types and specific regulations where data needs to be kept locally but it is less common.

So, what’s the solution?

Change the laws/regulations/perceptions

The truth is that many of the regulations that we are trying to adhere to were not written with today’s distributed architectures in mind. No one was thinking about accessing systems from smart phones, desktop virtualization, delivering anything “?aaS”. In fact many of the regulations were focused on access to physical assets not electronic distributions. These laws need to be cleaned up and made relevant to today’s technology. We need laws that protect data adequately in a way that can actually be implemented and monitored at the scale that we see today.

Have local deployments

The reason that non-cloud deployments do not worry about these issues is that the systems, the data and the staff are typically all deployed within a single country. So, if your cloud service provider will guarantee that your systems and data are in a cloud data center in-country then you are no worse off than with a local deployment.

This is often not the case, especially with the larger more ’generic’ providers. However, some cloud service providers (I should in good conscience mention that the EMC project I am working on does support this model) will allow the systems to reside in a local datacenter or even in your own datacenter. You might wonder how this can be a cloud solution if it is not “out in the ether” in a multi tenant environment? A local, single tenant instance of a system certainly loses some of the features of cloud deployment but it can retain some of the key ones too. Assuming that you host the cloud solution on a shared physical stack you can still get elasticity associated with a shared infrastructure through virtualization. If the cloud service provider will still manage the system remotely and provide the system as a local “black box” then this might be a compromise worth considering.

Use technology to protect

Let’s take a different tack. What does the regulation really say, or really mean? Let’s say that the data was physically stored in a different country but could not be accessed by anyone there. Would that satisfy the intent if not the letter of the regulation. If you stored your data in an encrypted form and only allowed the decryption to be done by people within your home country then you might be able to meet the actual requirement. Digital Rights Management (DRM) would allow for this out of the box today.

Another advantage of DRM is that it protects data in the cloud but it also protects it when it is taken offline. If you download a DRM protected document to your smart device the local application could in theory still protect it…imagine, it could do a quick retinal scan to identify you, look at the GPS coordinates to see where you are and then decide whether to give you access. Orwellian or what?

Don’t use the cloud for that type of data

The reality is that today the cloud is not a panacea for all content, in all cases, in all locations. In five years it will be the de facto delivery system for most applications but maybe not quite today. You might decide to keep certain systems locally for now until things mature. My advice however is not to throw the baby out with the bathwater. Just because some systems might not move into the cloud today doesn’t mean that you cannot move others. In fact, take the opportunity to offload the less critical systems into the cloud and focus your management efforts on the remaining systems.

Conclusion

You are going to have to be creative and flexible if you are concerned about any of these issues. These boundaries exist because of infrastructure, physics, lawyers and politicians. Infrastructures will evolve, physics can be manipulated (we almost had Neutrinos traveling faster than light recently) but the lawyer/politician thing isn’t going to be solved any time soon.

Truthfully, this is just another indication that the cloud is still maturing. It is growing up much faster than the surrounding practices, laws, regulations and culture These growing pains are going to be a challenge for a while longer...

Cloud Computing Business Considerations - Compliance to Regulations

Is moving regulated content to the cloud really an issue?

I’ve worked in product management of enterprise software for about 10 years now including heading up the EMC Records Management group for a while so when we started looking at the security implications of moving our systems to a cloud delivery model I was skeptical to say the least. Why? Because a move to the cloud surely means that you are putting your company’s assets out where any decently equipped hacker can access them without breaking a sweat...doesn’t it?

As we worked through the choices of cloud architectures it became apparent that actually a move to the right cloud-based system with a cooperative vendor could actually reduce your compliance exposure. Don’t believe me? Read on.

We have to start by separating cloud solutions by “available connection points”. That is, what is your cloud solution connected to? The public internet or directly into your secure corporate network? It is important that you understand this differentiation because it will have a huge impact on your risk profile after deployment.

Comparing Public and Private Cloud Solutions

• A public cloud solution is plumbed directly into the public internet; typically anyone can go to www.SomeCloudURL.com and access the cloud solution. This makes it ideal if you want public access but remember that this means that although your target audience can easily access the systems, so can those hacking miscreants.
• A private cloud does not have a public address; it is plumbed directly into your existing corporate network via a secure connection, (VPN for example). Only people inside your corporate network can get to those services.

Moving to a Public Cloud Solution

I am not going to say that a move to a public cloud-based solution will never work for content that you need to protect but I will say that your considerations to protect the data will be far more arduous. You will have to assume that undesirable types absolutely will get into the system and you should build your protection based on that premise.

I am actually not going to pretend to be an expert in enforcing this level of security, instead I am going to focus in on the approach that we took which is to remove the public access point and deploy solutions as a private cloud. This works well for enterprise systems that are typically used by internal people or integrated into existing internal systems.

Moving to a Private Cloud Solution

If your cloud service provider connects your instance of the solution directly, point-to-point, to your data center using a dedicated, secure connection then you have a cloud solution that is effectively just an extension of your existing data center, your current security model and your internal network. If the provider is flexible and will work with you on the connection, security, monitoring, authentication, etc. then the polices that you already have in place for protecting data, authenticating access, regulating the distribution of content etc. can often be used as-is. You get the benefits of the cloud delivery without giving up security.

In fact, the only significant thing that really changes when you move to a private cloud based solution is where the content is being stored. If you work for a large company then you already have data being stored in many locations – backups, remote servers, laptops, smart devices, etc. At least with a decent private cloud provider you will know where it is.

When you position it like this the move to an off-premise deployment does not seem quite as scary. In fact, if your service provider can illustrate how the content is protected from unauthorized access and you are ok with the location of their storage/backup then the move could easily enhance your compliance.

Access to protected customer data.

I’m calling this out as a specific topic because it is a recurring concern especially in some regions. As an example let me paraphrase HIPPA, you “must make reasonable efforts to disclose, only the minimum amount of health information needed to accomplish the intended purpose”. We translate this to say that only authorized people should have access to the health information and that they should only get to see what they need to see.

If your system can be accessed by administrators from your cloud service provider then you need to ensure that those admins have only the appropriate level of access to that health information. What is an appropriate level of access for them? None would seem like a good level. So you need to ensure that (1) the system admins cannot access the data and (2) if they do then you are notified of the breach.

Before you start to panic take a look at the sentence above,”If your system can be accessed by administrators from your cloud service provider…” and now replace “cloud service provider” with “internal IT department”. HIPPA doesn’t say that it is OK for your own internal IT department to see my medical data. Your HIPAA compliant application must already know how to protect data from your admins; it must be providing security and encryption levels to protect data from your own admins. You simply need to ensure that same protection is extended to the service provider.

You may need to ask your service provider to show you their processes to see how they will audit any attempts to bypass the application’s security but as long as the application can enforce the regulation then the move to the cloud should neither add to nor remove any of these controls.

So that’s it?

Pretty much, as usual the devil is in the details but remember that a move to the cloud is never going to solve any of your compliance issues, just like upgrading your hardware or network switch isn’t going to. Your compliance challenges will typically be solved by the application and your processes not the location of the servers.

Connectivity - Client, server and user locations

This entry is part of a series of postings that consider the challenges of deploying enterprise software into the cloud. I added this topic to the list because it does not really fit into one of my original categories. The topic relates to where you might deploy each part of a stack from end user to core servers and how that might affect the performance of your systems.

One concern that people often bring up is that moving any part of an enterprise deployment model into the cloud will naturally cause degradation in performance because of increased latency. In reality this is not always the case. Read on...

The Non-cloud Model

Think about the deployment of an enterprise system with a thin (web-based) client to a user sat in the office in the same building as the data center.

In the conventional (non-virtualized/non-cloud) deployment model the core system server and the web application server will be positioned very close to each other. Often they will be physically in the same data center with a fat umbilical cord of fiber linking them together. So very little latency there and no real bandwidth issues either. The end user connects to the local application server from her office and it serves up the client application into her browser.

The Perceived Cloud Model

The concern comes from taking the core server and web application server out to “the cloud”. Now those servers are in some undisclosed remote location. Now consider what happens when the user navigates around the repository and finds a nice fat 120MB PowerPoint presentation to download. That file needs to get from the web application server to the user’s desktop over the ether. Now she has latency and bandwidth challenges up the wazoo (technical term). The 120MB presentation is going to be downloaded lock, stock and barrel to the user's local desktop. Once it has all made it down (no byte streaming a PPT) she can open it.

It is the addition of this WAN layer into the architecture that concerns users of enterprise systems.

The Reality of the Cloud Model

Take the same business requirement: the user needs to work on her 120MB PowerPoint presentation which is on a server in the cloud. But now add something else that the wonderful world of virtualization gives us - virtualized desktops.

With a virtualized desktop the user uses a client application to connect to the instance of a desktop that is actually running on a server in the data center. The user sees that desktop and can interact with it from her machine but the OS and applications are actually running on the machine in the data center. In this image the user is actually using an iPad but the virtual (remote) desktop is running Windows.

All the user gets on their local machine is a "screen painting" of what is happening on the virtual desktop. So when she opens a 120MB PowerPoint file now it is actually transferred to the virtual desktop (which is running on a server in the data center) and opened there. The user sees the PowerPoint file open in seconds and can edit it, can email it...she can do everything that she would normally without the file ever moving across the ether to their machine.

Summary

So, why don’t we just virtualize all desktops? In the world of “choice computing” this might be a reality sooner than you think but don't get me wrong, there’s a litany of pros and cons to this approach. As well as performance there are other positive implications in security, desktop management, virus control, etc. However it might not work for everyone. I'm sitting on a United flight to Australia right now and there's no WiFi on the flight so I can't access a virtual desktop at all, also if you need very high fidelity or need to interact with files on your local machine then today’s virtual desktops might not work for you.

The balance of virtual desktops vs. local thick clients vs. conventional thin clients is going to be a balancing act for a while but for sure the virtualization of the client can make the cloud deployment model a reality for applications where it just may not have made sense in the past.

Customized Solutions in the Cloud

This entry is part of a series of postings that consider the challenges of deploying enterprise software into the cloud. Specifically, how to customers can solve their unique business problems in the cloud. Normally customers will customize their environment to suit but the cloud is an environment that typically does not tolerate customer-specific customizations.

As usual this is a balancing act. If you can take the cloud solution “as-is” and just configure it then you are in the best place from a technology and risk perspective. If you can isolate your custom processes outside of the core cloud offering then you can still leverage the benefits of the cloud but still have your custom processes. If you have to customize the core solution then you may have to stop calling it a “cloud” solution and call it an “managed service” or “hosted” model; not as sexy on your resume but a more accurate representation IMHO.

Why does the cloud create a customization issue?

Technically it isn’t the “cloud” or even multi-tenant models that cause the issue. It is the fact that the cloud provider wants to manage a large number of systems ‘en masse’. Specifically, they want to be able to push out updates, patches and performance enhancements to all of the systems without any risk of something in a specific instance breaking.

This does not just increase the hosting company’s profit margin it also gives you a much higher quality end product. How? If hundreds customers are all using exactly the same stack of software, at the same patch level and on the same hardware configuration then the chance that you will find an environmental bug is much lower. Also, the software developers will typically develop the code, do QA and benchmark on that exact stack so you have the most optimal environment possible.

So, we have established that the cloud provider wants you to run on a predictable platform. What does that mean from a practical perspective?

Customization vs. Configuration

People a lot smarter and more eloquent than I am have explained the difference between configuration and customization, usually around "writing code" vs. "using an admin client or changing XML files". However, in this case the difference is a little more specific. For the cloud, a configuration change is something that will not change the service provider's ability to manage the environment in a predictable way. However, a customization is something that removes that predictability.

The Problem with Customizations in the Cloud

An example of a customization might be custom code that writes to a non-standard database table or bypasses the standard APIs to perform operations using direct service calls.

• Writing to non-standard database tables: As the cloud service provider I have standard processes that backup the database tables...at least all of the standard ones. If my scripts don’t back up your tables and you need them to be recovered then you’ll be mighty upset. Even you adding a non-standard index to a table could be enough for one of my performance updates to take down your system.
• Bypassing supported APIs: The cloud provider’s contract with you is probably that they will document all API changes, give you fair warning before they start to deprecate functions etc. That contract only relates to the supported API set, they can change other private API calls without telling you.

Remember that in a multi-tenant model if you take down your system by bypassing these controls then you could also be taking hundreds of other systems down at the same time so the service provider is unlikely to make exceptions.

Your options: configure, customize or try something else.

Configuration:

By far the best model is to move to a configuration-driven solution. This should include configuration components for clients, server services and admin tasks. Vendors moving their solutions to the cloud cannot continue to rely on the model where they “are an open, fully extensible, platform for your custom applications”. To survive, vendors need to wake up and to start to support complex, business driven and predictable configuration-only models.

Customization:

I think that vendors need to make a call here.

1. Don’t support customizations – this restricts what your customers can do in the cloud but supports a low cost model.
2. Allow customizations but know that your cost to manage the services just increased exponentially and involves a lot of professional services work.

The latter model is closer to a managed service than a typical cloud deployment.

Something else:

This is the area where there’s the most latitude and opportunities for some creative thinking, maybe just until the configuration models mature.

Ideally, we are looking for a model where the customer gets his/her customizations but the cloud service provider still gets the predicable, uniform environment to manage.

Isolation:

The core cloud offering runs without any custom components/services but it communicates with a custom environment that includes all of the customer’s specialty code. The cloud provider can manage the core environment en masse and then someone (the cloud provider, partner or customer) is responsible for ensuring that the isolated custom pieces survive any changes to the core system. This model can work well in many cases but is predicated on the custom code not needing to run on the same servers as the actual core systems. This can work especially well for custom clients and interoperability with 3^rd party systems where the delineation is clear.

Certified Customizations:

This sounds good in principal but the reality is a little less clear. In this model the cloud service provider will publish a guide to the operations and behavior that can be tolerated in a customization. A 3^rd party (e.g. the customer or a partner) will build the custom code to that specification. An audit of the source code will be carried out which will ensure that only supported actions are being taken.

In theory, this means that the code will support the en masse management while also giving the customer the custom behavior that they need. So why isn’t this a clear winner?

1. It is expensive to carry out the certification process.

2. The process is not always 100% reliable at finding potential trouble spots.

3. Partners/customers may not be comfortable handing over the source code to the service provider for the audit.

4. In many cases the custom code will make calls to third partner components that are not available to be certified.

OEM the Cloud:

In this model the cloud service provider makes available the core product offering to a partner who then builds their solution on top of that. The partner is then responsible for delivering the end solution to their customers. They take the updates from the cloud service provider and certify that they will not do any harm to their end product before implementing them.

Conclusion

As I said at the start, this is a balancing act. If you can take the cloud solution “as-is” and just configure it then you are in the best place from a technology and risk perspective. If you can isolate your custom processes outside of the core cloud offering then you can still leverage the benefits of the cloud but still have your custom processes. If you have to customize the core solution then you may have to stop calling it a “cloud” solution and call it an “managed service” or “hosted” model; not as sexy on your resume but a more accurate representation IMHO.

Cloud Computing Business Considerations - Overview

What are the business issues that you need to consider when moving corporate assets into the cloud?

In 2011 when we started the project to move the EMC Content Management products into the cloud the list of issues to be resolved seemed daunting and only vaguely defined. I started blogging about each of the issues and just recently realized that my list of issues was really not so daunting after all. I just posted an article about the encapsulation of all of the issues. I also posted a number of articles about virtualization of enterprise systems which you might find enthralling.

Rather than overwhelming you with all of the issues I’m turning this into a simple list of the articles that you might be interested in…

	The single most important document
	Pricing Models
	Compliance to Regulations
	Dealing with Data Center Placement
	Client, server and user locations
	Customized Solutions in the Cloud

If you’re looking for the original list then here it is or I’m sure that Google will have it cached from pre July 2012.

Core Business Issues: Service Level Agreements, Pricing, Liability/Insurance, License ownership, Compliance to Regulations, Exit strategy,

Initial Implementation Issues: Data Center Placement, Services, Migration, Connectivity - Client, server and user locations, Connectivity - Enterprise applications, Customizations

Day-to-day Management: User (de)provisioning, Monitoring, Location issues, Backup, HA, DR, Patch management, Environment management,

Mobility and the Cloud

So this topic came up in one of the sessions at the Cloud Computer Expo during a Terremark session and I think that it stands alone for those of us in the enterprise software space.

When you say “Mobility” in the context of clouds people start to think about moving VMs between environments but if you accept that all enterprise clouds will have some element of hybridity (wow, that’s a real word!) then you have to accept that there will be differing levels of mobility depending on what you are looking at. You are going to have systems in the cloud and systems on premise and they are not going to work in isolation.

Here’s my swag at a list of potential mobile elements.

• VM images – infrequent. You don’t want to move these puppies around other than in a very controlled fashion. Movement between dev, test and production or from on-premise to off-premise during initial deployment perhaps. Moving VMs because you change cloud vendors is rare and probably not a good idea.
• Data objects – frequent. The chances are that data may be flowing back and forth on a regular basis. Best case (least movement) you are going to bring data back on premise as you realize that it is:
• Needed by another process
• Just became a record (formal or informal)
• Is subject to a subpoena
• Should never have been out there in the first place
• Metadata – frequent. Probably even more frequently than data objects. Imagine that you have an ERP system in the cloud but you store your attachments on premise. The synchronization of metadata about these attachments needs to be mobile.
• Log data/reporting – frequent. Not a big payload but there’s a good chance that your internal team are going to want to be able to store and analyze log/reporting data locally. If they don’t then you probably have not finished your audit qualification process yet.
• Configuration Information – moderate. Maybe it is user account information, group membership, policy changes…whatever it is you will have to be able to push/pull this on a periodic basis.
• Software (patches, etc.). Oh yes…depending on the model, someone needs to push changes out to the actual enterprise software.

Is this a comprehensive list? Have you ever seen a comprehensive list from me? I’m guessing that you get the point though; you will probably never see a real ‘Cloud only’ deployment of enterprise software and the thing that makes it hybrid is that relationship to the other systems. Why never a ‘Cloud-only’ enterprise deployment? Because by definition enterprise software means playing as part of the larger enterprise ecosystem and you don’t do that on your own.

Oh, the graphic? You need to be British and over the age of 35 to understand that one.