Your SlideShare is downloading. ×
  • Like
  • Save
Rapidly Deploy Enterprise Cloud Sandboxes
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Rapidly Deploy Enterprise Cloud Sandboxes

  • 434 views
Published

View our presentation to learn how you can use cloud computing to rapidly deploy enterprise cloud sandboxes.

View our presentation to learn how you can use cloud computing to rapidly deploy enterprise cloud sandboxes.

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
434
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Rapidly Deploy Enterprise Cloud Sandboxes
  • 2. Challenges Building Enterprise Sandboxes
    Environments not always a mirror of production
    Hardware is different
    Software configurations drift
    Hardware procurement tends to take longer
    Sandbox Resources are often cannibalized
    Perfectenvironments are costly to build
    Why spend so much capital and people on something that will be used so little?
  • 3. Agenda
    Approaches to Creating Sandboxes
    Building Test/Dev Environments in the Cloud
    Impact on CapEx and OpEx
  • 4. Approaches to Creating Sandboxes
  • 5. Script Based Approach
    Logic and knowledge is encoded into a script
    What software is deployed
    What settings need to be configured
    What needs to be provisioned
    Benefits are:
    Easy to develop
    Fast
  • 6. Drawbacks of a Script Based Approach
    Changing the environment significantly requires intensive reworking of the scripts and new testing
    Adding nodes, changing configurations all fall into this category
    Highly customized and not reusable
    Fixed for what you are building
  • 7. Properties of a Model Based Approach
    Abstractly defines the system you are building
    Similar to UML diagrams and Visio diagrams
    Dependencies are modeled into the system
    Settings are encoded
    Any part of the model can be replaced independently of each other
  • 8. Benefits of a Model Based Approach
    Codify your software configurations
    By codifying configurations you reduce the drift that tends to happen between production and test/dev environments
    Standardize your hardware configuration
    By standardizing hardware configurations you reduce the differences in performance and behavior
  • 9. BuildTest/Dev Environments in the Cloud
  • 10. Provisioning Test/Dev Environments
    With either a public or private cloud you can rapidly provision a test/dev environment on demand
    Benefits are clear:
    Test when you need to
    Create a variety of environments for exhaustive testing
    Evaluate different configurations for optimal performance quickly
  • 11. Considerations with Building Environments in the Public Cloud
    Some public cloud providers standardize on instance sizes.
    EC2, Rackspace, etc don’t allow you to customize the virtual machines
    Some virtualization platforms allow you to define bundles but these are not necessarily what is provisioned
    You request 4 CPUs and you might get 2 CPUs depending on availability
  • 12. Considerations with Building Environments in the Public Cloud
    Not all resources are accessible from the cloud
    Public cloud vendors have instances isolated from your network (except for VPC)
    So most applications which interop with internal systems may not be able to function
    Cannot mimic network topology
    Sophisticated network configurations are not possible in public cloud environments
    12
  • 13. Impact on CapEx and OpEx
  • 14. CapEx and OpEx Changes
    Provision an environment when you need them and de-provision the environment when you are finished will increase you OpEx
    Incur costs only when you are in a testing period
    Do not incur the costs when you are not testing
    But by not having dedicated servers on premise you decrease your CapEx
    No longer buying servers in perpetuity.
    In addition overall OpEx can decrease since you no longer have to maintain servers on premise
  • 15. Caveats with Testing in the Cloud
    Cost of public cloud computing is not necessarily competitive with internal pricing
    Typical costs range around $0.015-$1/hr for an instance in the public cloud
    Internal pricing is comparable if you factor in the following:
    Electricity
    Rent
    Personnel
  • 16. What is the Decision Point?
    Pricing decision should be based on:
    Quality of the test environments
    Time to establish environments
    Speed of decision making
    Balanced against:
    Problems that result from poor testing
    Time lost waiting for environments to be created
    Cost of indecision
  • 17. Thank you for attending!
    Interested in learning more? Please contactpeterc@elastra.com
    Please sign up for our next webinar on Friday September 18th, at 10am PST
    Topic: Amazon Virtual Private Cloud
    Basics of VPC
    Implementing Cloud Bursting
    Benefits of Extending your Datacenter