Extending Your Infrastructure & Data to the Cloud

Editor's Notes

• #8: I’m trying to create some slides that tell the “how symform works” story in a butt simple way.  The first slide in this deck is how we do it today.  And for techy folks, they get it.  However, we need a way to tell it that is more graphical and simpler.  I’ve created two slides that attempt to do that, but I’ve taken just clip art or shapes or whatever.  What I need are some better pieces of art – I still think they should be simple illustrations like these – for each part of the story.  But I’d like them to be consistent style and using our branding colors.   I think the best analogy of how we “shred” data is a shredder.   There is no deadline for this, so maybe over next 2 weeks, you could think about it and play with graphics a bit.  What do you think? If we do this right, we should be able to create a fun video of this, too.
• #33: CloudSwitch was built with the hybrid cloud in mind - how to make it easy and secure to extend your data center to the cloud. New and legacy apps can be deployed into the cloud with point and click simplicity and managed as if they were running locally. CloudSwitch helps large enterprises with provisioning or moving– simply, securely and with NO modifications. Our whole reason for being is to make the cloud feel like a secure and seamless extension of data center environments. Our value prop is to move applications to the cloud without changing anything , and with connectivity back to the data center with security that meets the CSOs needs. This has great value for enterprise IT. With CloudSwitch:Cloud resources are secured end-to-end as an extension of the enterprise's security perimeter - all data and communications are encrypted and stay in the control of the enterprise.The entire system is isolated, the key management is completely isolated so only customers have access to the keys and not the cloud providerApplications run in the cloud without modification – no need to re-architect an app for a specific cloud.Users can manage applications running in the cloud using existing management tools and processes, just as they did before.Enterprises are now free from cloud lock-in, able to move applications to the right place as needed -- to another cloud or back to the data center.
• #34: The CSA is an OVF formatted virtual appliance deployed in your data center. Once configured to point to ESX servers – you can migrate virtual machines or provision virtual machines in the cloud. When you start the provisioning or migration we automatically launch an initial node (the CSI) – secure initial gateway into the cloud to protect and data and communications. Once that is in place you have secure connectivity to the cloud. The crux of our technology lies in the cloud isolation technology which creates a secure envelope that encompasses your entire cloud deployment. – with this secure envelope you have full network and disk encryption end to end from inside your data center, across the internet and through to the cloud. Encryption keys are always under your control inside your data center so the cloud provider only sees encrypted connections to servers and storage. Here is the end result – you have your virtual servers running on our cloud isolation tech - your images retaining all its patches. You have seamless connectivity by virtue of the appliance and the CSI. Secure, layer 2 bridge so these machines look exactly as they would in the data center – connectivity to DNS, LDAP , IDS, etc..
• #36: Biogen use case: continuous integration (Hudson for JAVA compilation) Customers dip their toe in the water with app/dev use cases. We provide a secure connection between the DC and the cloud (CSI) and this allows customers to put sensitive information in the cloud
• #37: Hosting app in DC , bursting to cloud (large financial services ). Add servers in the cloud to your load balancer , and then dial up and dial down as necessary. You can do this programmatically via our SOAP based web services interface or via the load balancer’s interface. Typically you monitor this via Gomez and NagiosThis is a hybrid cloud model – the customer had a physical DC , hosting an app to the public. They faced cyclical demand during market open and market close. Their options were to buy more hardware , build out the infra or burst into another environment. They chose to use the cloud for a “burst” use case. In peak periods demand would be sent over to the cloud
• #38: This slide depicts a sample HPC cluster deployed entirely in the cloud. The terms used are generic, however a relevant specific example is Oracle’s Grid Engine sitting on top of infrastructure managed by Rocks Cluster. In this model, there are four primary components in the cloud:Queue Master: Responsible for orchestrating job activity across compute nodesProvisioning Server: Responsible for managing the operating system provisioning process for new compute nodes.Data Server: Responsible for housing the data sets consumed by the compute nodes.Compute Nodes: Responsible for the actual “number crunching” as managed by the Queue Master.The primary end users are scientists and researchers, generating data through specialized research equipment. This data is then transferred into the cloud for analysis by the compute cluster.The CSA manages all infrastructure allocation, providing raw, cloud-based resources for the cluster and orchestrating server lifecycle actions for these compute nodes in the cloud using our SOAP based web services interface
• #39: First view, shows all virtual machines running in the cloud. A few running in Enterprise Cloud, Express and Amazon. Highlight that we have server lifecycle options , expand the server to provide more details on the server. Show the IP column, these are private IP columns , not the IPs given out by cloud providers. We can support multiple NICs on a server. RBAC allows you to control who can do what in the CloudSwitch console. VM and ISO locations, this is how CloudSwitch connects to ESX hosts – that allows us to drill into an ESX server to select one or more servers for migration. Automatically select the right cloud resource to map to your virtual machine’s profileWhat type of latency? When a customer migrates out of the DC to the cloud that is obviously introducing latency – the physics of it introduces latency. The encryption and the arch – what latency does the CSI introduce? It varies, generally we are anywhere from 1ms to 5 ms worst case. There is tons of traffic flowing through the CSI – it is busy performing encryption , decryption. Typically we are in the 2 ms to 3 ms range. One of the follow-on questions – what is our tolerance for latency? If it is a very high transaction app you probably don’t want to put your DB in DC and app in the cloud. That will slow things down as you commit writes to the DB – that is in general a poor design regardless of the cloud. In terms of perf overhead – it depends on what the app is doing. Compute intensive apps (eg: number crunching, processor bound work) – those run fast in CloudSwitch. In some cases they run faster on us because we do some optimization on thigns like register access to improve efficiency. We run processor benchmarks to test our own overhead and some of them indicate that we are faster. However, apps that have high transactional IO you will see a slowdown because of encryption and our own isolation tech as we handle things like context switching.