MemorableURL.com

IIG’s Acquisition of Syncplicity for Sync and Share. What’s that all about then?

So I am sure that you have heard by now [Press Release] that EMC IIG (the group that brings you Documentum) has acquired Syncplicity which is a company that provides a SaaS-based ‘sync and share’ solution.

OK, so here’s what I know…and my interpretation of what’s going down. Remember that this is reflects my personal thoughts on the announcement not the official line. Also note that I was given advanced notice of this acquisition but not much notice!

Firstly, in line with the rest of the IIG products the key audience is not the consumer market; it is the core Enterprise market. The offering is differentiated from the other 20 or so Sync/Share solutions out there because it seems like it was engineered with the features that IT, the businessand end users ask for. For example, I know that a lot of the more consumer solutions out there are actually blocked by corporations’ IT departments because they don’t provide the control or security that IT and the compliance groups need.

At first I was a bit confused how this acquisition aligned with our definition of “ECM” but then I realized that by specifically selecting Syncplicity it aligns pretty well with the three key focus areas of the business. You might know that the IIG strategy for the last few years has been the move to the Cloud, a focus on the New User, business transformation and pervasive governance. Syncplicity’s focus on an enterprise approach to Sync/Share actually aligns with all four of those focus areas.
So what do I mean when I say that this is an ”enterprise” solution as opposed to a more consumer solution? From what I know, the Syncplicity solution adds a lot of the elements that the IT and compliance groups need:

- More security,
- Bandwidth throttling,
- Some serious encryption
- Remote wipe
- SSO
- Ability to scale
- Support for a wide selection of platforms
- Customer controlled policies

It also integrates into a lot of the enterprise suites in play today and seems to work without actually changing the way that the other solutions work leaving the files on the desktop or file server just as they are today – SalesForce, SharePoint, Google Apps and Google Docs don't change for the end user at all. I am going to wait for more official communications have been crafted before I comment on how this might affect the core Documentum suite but I think that it can only be positive for the business.

Interesting times indeed…

EMC OnDemand at EMC World/Momentum

I am usually adamantly against advertising EMC-specific things but I’ll make my annual exception for EMC World next week. I’ll be there with quite a few members of the OnDemand team talking about how we got Documentum, Captiva and xPression running in the cloud without sacrificing any of the rich functionality.

If you are attending and want to learn more about OnDemand then here’s a list of the sessions that are most relevant. I’m presenting some of them but I won’t say which, it’s more like Russian roulette if I don’t tell you.

Hope to see you there…

I’ll tweet with annoying regularity from @chapmaa and use the tags #MMTM12 and #EMCworld

---

Mon - 10:00-11:00 : Capture in the Cloud – Your Journey Starts Now
Get an up-close look at EMC Captiva OnDemand.

Mon - 2:30-3:30 & Wed - 10:00 - 11:00 : An Introduction to EMC OnDemand - EMC Documentum, Captiva & Document Sciences
Heard about EMC OnDemand but not sure what it can do for your organization. Learn how this offering can simplify system maintenance processes and save your IT department infrastructure costs

Tue - 11:30-12:30 : Lifetime Fitness Turns to EMC Captiva OnDemand for Invoice Processing
This session will focus on the business justification of deploying Capture systems to the cloud and why EMC OnDemand was the right fit.

Tue - 4:15-5:15 : EMC Documentum OnDemand: The Nuts and Bolts of Determining if EMC OnDemand is Right for You
Understand the benefits of transitioning to EMC OnDemand, find out if you are a good candidate for EMC OnDemand, and hear about roles and responsibilities should you make the move, along with other considerations including data privacy, security, industry certifications, performance and more.

Wed - 8:30-9:30 : EMC OnDemand and EMC Documentum D2 – Improve Time to Value, Respond to Change Faster and Decrease Cost
Want to decrease solution deployment time, be more flexible, focus your resources on the business and reduce your total cost of ownership? Who wouldn’t?

Thu - 8:30-9:30 : Understanding EMC OnDemand 'Cubeology': A Technical Deep Dive
A deep technical evaluation of the blended architecture. From there you’ll understand the entire ‘Cubeology’ as well as security and data privacy, portability, HA/DR and the ability to pre-configure applications from dev, test to production.

Thu - 8:30-9:30 : A Preview of EMC Documentum xCP 2.0 Cloud Development
This session previews the capabilities and benefits that our customers will have by building and deploying xCP 2.0 applications OnDemand. This session evangelizes cloud development and provides customers and partners an example “roadmap” to the cloud for xCP applications.

Thu - 10:00-11:00 : A Practical Guide to Moving to EMC OnDemand
The OnDemand model significantly reduces or actual eliminates many of the implementation steps required when compared to a traditional on-premise model.

Thu - 11:30-12:30 : EMC OnDemand for Document Sciences xPression: Moving Customer Communications to the Cloud
Gain insight into EMC Document Sciences xPression OnDemand and how you can benefit. 

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?

I am going to focus on the topics that you as a customer need to be thinking about as you move to the cloud. I’ll pick a topic at a time and expand on it in an entry and I’ll add new entries as I think of them. Just to set expectations: I might not have all of the answers but I’ll try to give you questions to mull over.

Core Business Issues
Service Level Agreements	Do you understand what you need from an SLA? Who is the SLA with? What does it cover? What are the implications of non-adherence to the SLA?
Pricing	How does the new pricing model work? Who ultimately owns the software? Everyone gets excited about OpEx vs. CapEx but is that ok for you? Maybe your OpEx budget is more tightly managed that your CapEx budget.
Liability/Insurance	Who is liable for what and do all the parties have coverage should it be called upon?
License ownership	Who is responsible for providing software licenses? For the core offering, 3rd party software, the OS, DB, add-ons etc.?
Compliance to Regulations	How to cope with compliance to regulations when you move your enterprise solutions to the cloud.
Exit strategy	Can you back out of the solution if it isn’t working out for you?
Initial Implementation Issues
Data Center Placement	Are you a global company? Where will you need data centers?
Services	Are you free to employ your preferred professional services companies or do you have to use the Cloud providers’?
Migration	Are you going to forklift existing data, processes, policies etc. into your cloud solution? If so, how’s that going to work?
Connectivity - Client, server and user locations	Where do you put each part of the architecture and when?
Connectivity - Enterprise applications	Can you connect in your other enterprise systems efficiently? What about connecting custom clients?
Customizations	What level of customization (if any) will the vendor support? This can range from zero to unlimited but there are prices to pay across the board.
Day-to-day Management
User (de)provisioning	Is there an unacceptable latency in how quickly users are provisioned and (more importantly) de-provisioned in your cloud systems.
Monitoring	Who is responsible for monitoring access violations, system performance, etc.
Location issues	Do you know where your data is? You might not care but some solutions need to know, (especially in the EU).
Backup, HA, DR	What’s your requirement for disaster recovery?
Patch management	Who patches what, when and how? Can you opt in and opt out?
Environment management	What environments are provided? Dev, Test, Production, Sandbox? What’s the connectivity between them, etc.



My thoughts on the week at the Cloud Computing Expo. Ugly Babies, Duct Tape and DevOps.

My one big insight – in the future when the Cloud Computing Expo has 50% of the sessions on cloud- based applications, end user solutions and real customer usage stories then cloud computing will have arrived. Right now it is just starting to mature...an exciting time to be involved!

• This is a fast growing but still immature space. This is obvious because:
• There are lots of very specialized vendors selling point solutions.
• Most people here are talking about the issues and not solutions.
• There's a lot of work going on in areas that should 'just work'. Most of these areas will become commodities in the longer term but right now there's a lot of duct tape holding lipstick onto pigs.
• The lack of clarity around industry definitions is amazing, the industry needs to agree on what some of these words mean!
• There's a severe lack of real-life customer use cases. This is odd because vendors stand on the stage announcing that they've been selling cloud solutions for ten years. To whom?
• The focus right now is on solving IT issues down at the IaaS level. IMHO this will/should be short lived because this really should be a commodity. The sooner we can move out of IaaS and be looking at eSaaS (Enterprise Software as a Service) the better.
• Segregation is probably going to be a big deal. The cloud aggregates things into a single location and sometimes that's not a good thing, we need to be able to segregate some things (data, access, services, etc.). Don't neglect to build your infrastructure to be able to withstand this data mobility.
• An even bigger deal will be policies. Not just for segregation but also for provisioning, access, etc.. Here's one...how about a policy for when you will take down unused systems in the cloud. I've ranted on about uncontrolled silos being a huge liability for ten years now...oh lookie, here's another one appearing!
• Security. we need to be able to secure the cloud, no doubt about it. We could do ourselves a favor however by *comparing* the cloud apps to on-premise apps. The elephant in this room is "how secure is your existing infrastructure?" Before you call my baby ugly take a look in your own crib!
• Self-service is a big deal but only because it is the key touch point with the end users but it really only solves once tiny part of the issue with the software lifecycle - deployment. Let's not get too carried away.
• Open source cloud solutions. These will help especially at the IaaS level and will play a large part in driving IaaS into a commodity. I want to see IaaSaaC not just be a biblical figure but a reality.
• One blocking factor is confidence. We need to find a way to get companies to try the cloud, the other might be related to IT departments and job security!
• Convincing IT that the cloud will allow them to focus on adding value to the business not just "breaking rocks" would be huge.
• Talking of IT...IT and engineering are going to have to form new alliances. DevOps was a word that I've heard bandied around a lot this week.
• One thing that I don't know for sure is "who is going to win". At any level of any part of the stack. What does this mean in an area like this? Don't get too tied in to anyone's specific technology if you can avoid it. Remember 'agility' is the word of the week.
• The cloud is global...rules, regulation, laws, etc. are not. Don't assume that the regulations that govern *your* data apply elsewhere. This one is a killer.
• Leverage the cloud, don't just move to it. If you think that a move to the cloud is just about moving from the on-premise datacenter to the off-premise datacenter then you will be missing out on a lot of the potential - especially the financial potential.
• Make sure that your cloud service provider will turn on the lights for you. Remember what "assume" did...
• Cloud computing seems to lead to Choice computing. If your cloud solution only runs on a VT220 terminal or Windows then you might not be happy with adoption.

The conference was very good, I'd like to see a few more customers speaking and many more sessions on deploying SaaS. Good energy level, friendly people and I didn't have to speak so I could dress like a homeless person.

Cloud Expo #4: Agile Development, CMOs and the Borg

The fourth and final day of the conference. I sat through a few higher-level, vendor pitches today which were ok but they didn't introduce anything blogworthy.

The “interesting” section today is the section Cloud Scar Tissue below.

Agile Development in the Cloud - Jan Aleman, Servoy

I wouldn't normally attend a session with 'Agile Development' in the title but this level of the stack seems to be very neglected. As I've mentioned in previous posts the focus seems to be on the infrastructure and platform layers. According to Jan:

• 65% of new offerings are SaaS
• 30% of total market is SaaS
• 70% of all software is on premise.

So, why not write your apps to run in both? Again the speaker reiterated that as a developer IaaS is of no interest to you, all you really care about is the PaaS layer. (Force.com and Azure are the leaders in the PaaS space.) PaaS gives you the multi-tenancy, security, I/O support etc. As a developer though, how mature are their development offerings? Are you locked in? Can you develop one code line and have it deployed into on and off premise.

I was hoping that this session would be a little bit more of an academic presentation about how agile development works in the cloud but it really was just a marketing pitch for their agile development platform. They use Eclipse as the UI and he did build an application in real time during the session which he published out to the web and we were able to use it from our iPads/laptops. That was neat but I didn't learn anything to take back to the office.

CMO Panel discussion

How much of a role does branding make in a Cloud company today?

One of the panelists said that none of the companies on the stage was big enough to have a real 'brand' technically. The challenge that I think they have is communicating their value in a way that people can understand. Marketing via t-shirts seems to be a valid and effective approach that they are using right now just to gain awareness. They are in the stage of just standing out and raising awareness.

The topic of Bloggers arrived. They see the blogosphere as a place to take your brand (it is agnostic, cheap and a leveler). In the blogosphere, 'cloud people' are relatively well behaved and it is fairly flat. For example, with security blogs we get huge spikes as things happen but in the cloud blogs it spikes less.

The most interesting thing to me? The marketing guys were very pragmatic which is probably because the companies are small and they are stuck the technical intricacies right now. I'm sure they'll change as their companies grow and they forget their roots!

Cloud Scar Tissue: Real world implementation lessons learned from the early adopters. Anthony Skipper, ServiceMesh

Best session of the week IMHO. Anthony walked through a comprehensive list of lessons learned in deployments. He had issues but he also had answers!

One big thing though...he said cloud provisioned systems are like the Borg, each one is the same as the others...what? Non-geek alert, intruder detected. I thought that the guy with the mullet and sandals in the second row was going into apoplexy. Dude, the Borg were not clones, they looked really different but were part of a common hive. I'll overlook this just because the rest of your session rocked but if you are going to quote Star Trek at a cloud convention then tread carefully my friend. ;-)

So, back to the session...Anthony listed the main areas where customers have issues. I'm not doing it justice but here are my highlights:

Not believing that org change is needed

• IT fiefdoms. IT and the business are not built around the same structure as the cloud. Your cloud implementation is likely to cross the existing organizational boundaries and IT needs to be prepared for this.
• Operations will be much closer to the developers and will have good feedback for engineering. Again, the organization needs to be prepared for this new relationship.
• Architects will be forced to come down from their ivory towers and become more 'real-time'. The effects of their work can be seen almost immediately and that feedback loop will change the way they think and work.

Boiling the ocean

• This was not about how quickly you can get to the cloud, it was more realizing that you are not going to move everything to the cloud, some systems may never move. Greenfield apps will have a much better chance to survive out in the ether but some of your existing apps will not. You need to decide whether to live with this, rebuild the apps or change your business processes.
• The more service providers that you use the more connection points you are creating. You might just want to have one...or as few as necessary.

Failure to simplify

• We've all heard the adage that "complexity kills". It is not uncommon for a basic VM to have between 80-150+ integration points. When you move to the cloud those integration points are still there but now they are away from your existing infrastructure.
• Think about this level of complexity and then realize that a decent sized company could be spinning up hundreds of images a day. If you have too many integration points or complex relationships then this may not be manageable.
• The integration points may not be automatable, if any part is not automatable then the entire process becomes a burden on someone in IT again.
• In the world of enterprise software this is very important, especially with legacy systems. Can you simplify the integration points? Can you fully automate the provisioning?

Vendor management relationships

• Negotiating contracts with cloud providers should not be underestimated as a task, especially for a large scale contract. This can take 6+ months just to negotiate the deal and this has been known to actually stop a project.

Believing the vendor hype

• Customers believe too much of the story. Companies claim to "cloudify" any existing app in minutes with a new widget. If this sounds like a reasonable claim then email me because I have a bridge that I'd like to sell to you.
• Watch out for cloud providers with their own management tools...sure "as eggs is eggs" those tools will not work across platforms.
• This was a very long list of things not to believe...maybe it would have been a shorter list if it was exclusive not inclusive!

Cloud addiction (consuming too much and not knowing when to say no).

• Think about how you are billed. If you cannot predict those billing factors then your costs could balloon. Is it I/O, storage, compute cycles?
• There are solutions that are cost effective in the cloud but as they grow they may be more effective to have on premise.
• People find it hard to believe that it might NOT be cheaper to deploy in the cloud because of the hype but the cloud is cheap because of scale...once you have that same scale in-house then you might not see the savings.
• Have a policy (that word again) to review whether the cloud solutions are cost effective

Failure to implement policies from the start.

• This is just a great opportunity to drive process improvements.
• don't forget that just because it is technically possible to move to the cloud doesn't mean that it is legally possible.
• What to do if a bright spark in the business starts his/her own cloud deployment armed with a credit card and a browser? What's your policy there?
• The policy list seems like it could go on for a long time so here's what I'd say. Moving to the cloud is like any other piece of technology. It will only facilitate the running of your business, it will not drive it. You need to know what you are trying to achieve.

How is it possible that Security wasn't on his list? He said that there are security solutions to most of the problems and he reiterated that moving to the cloud may improve security.

Cloud Expo #3: Segregation, Policies and Breaking Rocks.

Interesting Section

Almost without exception every presenter stands up and says “The single biggest issue is X…oh, by the way we have a unique solution for X.” but there’s definitely a pattern for the areas. You can easily see that the vendors will split into IaaS, PaaS & SaaS groups because they will all be selling into different parts of the business.

There are a few interesting themes that I hear consistently throughout the conference:

• The industry is focused on solving IT issues with the Cloud but we need to be focused more on solving the business problems.
• Policy is going to be the next big buzz word. Not just access control...users, workloads, datasets, geo, laws and a policy management system. Watch out for this – those of us in the ECM business have a lot to offer here. Who else has policies for n-levels of access, reporting, audits, retention, geographical placements, etc.?
• Segregation. Servers, services and data. The general theme here is that there times when you have to compartmentalize your ‘stuff’. If your infrastructure or apps can be location aware then you can more easily adhere to regulations.
• For example, UK HR data cannot cross the UK country boundary so if I am in the UK I can see local HR data but if I step over the border into Ireland then I should not be able to access that data. Also, the underlying storage needs to be location aware…no storage or backup off the UK soil. While we are at it, in theory IP packets should not be routed via servers not in dear old Blighty.
• That last one might keep you up at night…
• The cloud tends to give better predictability and reliability.
• Anecdotally one customer claims to get 100% success in systems deployed from the cloud but only 85% in conventional deployments. They claim this is mainly because expectations are better set and outcomes are more predictable.
• As a follow on from the anecdote above I’ve noticed that everyone quotes anecdotes and analyst surveys. I’m guessing that this is also a sign that we are in an immature area – not so much real data.
• I’ve noticed that the vast majority of devices are non-Microsoft. Are the cloud guys driven by ‘choice computing’ or are they just rebels or both?
• Already IaaS seems to becoming a real commodity. Why would you want to be given a VM when you could be given a platform?
• Love this - One customer was scared to move to the cloud because they didn’t trust it but then they had an independent assessment of their own data center and it only came out as a level2 facility. Whoops!
• In the c-level discussion one member of the panel said the following…and I agree entirely.
• The biggest challenge is how to message the cloud to the market. Stop using the language of a vendor and start using the language of an industry.

I’m going to keep the notes much shorter and relevant today…probably.

Day 3 Keynote | Ops or Apps - Who'll Own the Data Center of Tomorrow? - Pete Malcolm, Abiquo

Self-service gives agility, rapid provisioning, pay as you go and pre-built configurations for users to choose from. It also reduces the IT infrastructure load as they can focus on the physical world while users work at the virtual level. But there are risks too. The old black box/dark room issue again, we don't know what is actually going on in the cloud data center so how do you test resilience if you don't own and test the whole stack?

The answer? 'Policy based automatic allocation'. This is automation of provisioning of systems. Deciding where they will run, what resources will it consume, which hypervisor to use, server segregation, data segregation, load balancing, co-locating with the servers, etc.

A self-service model needs to include "full empowerment". If your user needs to call IT for anything then this does not work

• Provide Compute (create VMs) - we do this well,
• Storage - can you support the appropriate class and amount of storage without calling IT to provision this. This is often not done correctly.
• Networking - can you auto provision the isolation, manage the firewalls, load balancers etc?

We need policies to drive the automatic, self-service provisioning of environments.

The Inevitability of an Open Cloud - John Engates, Rackspace

When most people say cloud they are imagining the Public Cloud. These tend to be proprietary; AWS, Google app engine, Windows Azure, force.com etc. You tend to get locked into these technologies, the alternative approach is to build a private cloud. Often times this is no less expensive or complex than your existing on-premise solution.

The answer…Open Source!

"The Cloud will have an Open Source OS". OpenStack is open source cloud software starting with infrastructure as a service IaaS based on technology originally written by Rackspace and NASA. Citrix and Dell were part of the initiative too. Three components in the OpenStack are: Compute, Object Storage and Image Service (VM images not scanned).

CEO Power Panel | Enterprise-Level Cloud Computing: Far-Off Dream or Present Reality? Lots of C-level people

Question 1: What's the fly in the ointment?

• It’s still very immature. We are at the “386” stage...but the pace of change is amazingly fast.
• Compliance and security need to be dealt with if we want the enterprises to adopt the cloud.
• Only 6% of IT staff are using the cloud...which means that 94% are not.
• It’s not about technology right now; it is about confidence in trying it. Start with something low risk to get the confidence.
• We start crossing the chasm this Thursday, (after the conference ends and we all get back to work I guess).

Question 2: What has happened recently that makes you feel good about the cloud?

• One word? “Easy.” One click, one system.
• The biggest challenge is how to message the cloud to the market. Stop using the language of a vendor and start using the language of an industry.
• The cloud business was being driven by gaming in the cloud but it seems like we are moving towards enterprise apps.
• Told a story about a company that went out of business but no one told (or paid) the cloud vendor...the servers kept running for three months serving customers without anyone doing noticing…they just kept running. I’m not sure if this was good or bad but I get the point.

Question 3: What's going to change in the next five months?

• More scale in both directions
• Easier
• More confidence in the cloud

I enjoyed the panel discussion until one of the c-level bods started a self-serving commercial for their products and every other one then followed suit…

The Big Win: Stop Playing Small-Ball with Your Cloud Strategy - Dave Roberts, ServiceMesh

Nothing that we had not already heard in this except that he said that thje reason that convicts used to be made to break rocks is that forcing people to do meaningless work that serves no purpose is mental torture. Much of what IT does falls into this category today but the self-service cloud model allows them to break out of jail.

If you are a large company then you are already at scale so why would cloud be cheaper? Virtualization

Think Outside the Box - Creating a Hybrid Cloud Storage Infrastructure the Unconventional Way - Peter Chang , OxygenCloud

I nearly didn’t attend this one because i wasn't sure that I care about storage virtualization but I'm glad that I did. Here's the proposition at a high level. Your app probably expects its data to be on a local storage device. If it can cope with the data being out in the cloud then it probably expects it to be in a single cloud location. However, what if you want to have some data in a private on-premise cloud, some in Amazon and some in a private off-premise cloud? While we are at it, how about applying some cross location caching rules and enforcing consistent policies across objects on these disparate devices?

Oxygen Cloud's solution stops your app talking directly to the storage in the cloud (public or private) and instead it talks to a middleware layer that aggregates and normalizes the communications. They call this layer a "cloud storage broker"

Across all of the layers in the broker is a security layer, for example encryption may not be consistent across the Cloud storage devices but encryption from the broker would be common. Oxygen effectively makes cloud storage look like a simple storage device so you can open a file from the cloud from within Windows. By presenting the storage as a file system oxygen creates a synchronization/caching model. This allows them to deal with network latency by caching locally and by optimizing data transfers.

Controlling Cloud Sprawl - Rodrigo Sousa Coutinho, Outsystems

We focus on the problems with the cloud:

• Data outside of the enterprise
• Immaturity of lifecycle
• Vendor lock-in
• Integration

But note that these are IT problems, we should focus on what the business wants:

• Instant gratification
• Flexibility to change
• Easy to get in

When the business gets answers to these three points then they buy!

A recent survey showed that 20% of the business people questioned had bought cloud services without IT’s knowledge. There reasons are listed in the slide…check out the last one on the list. Priceless!

PCI and HIPAA Compliance in the Cloud - Jeff Uphues & Stacy Griggs, cBeyond

Good little session this but it was all very low-level compliance stuff. They made yet another reference to the fact that the cloud might be less of a compliance issue than your own datacenter. In the case of HIPAA who is more likely to be able to protect your data? The admin in your Dr's office or a major cloud provider?

Using vApps to Simplify the Deployment of Multi-Tier Applications in the Cloud - James Weir, UShareSoft

The speaker did a great job considering it was 7:00PM…

At a super high-level, UShareSoft has a toolkit that allows you to have a template for building a specific vApp. Once you have all of the steps programmed to provision a vApp the tool can then build one for any specific hypervisors or Cloud vendor. The tools allow cloud providers (internally and externally) to create a "cloud app store" from the set of template.

A real point solution but for many of the legacy application companies this might be very useful.