Get the Most Bang for Your Buck with #EC2 #WINNING
â˘
1 likeâ˘683 views
by Boyd McGeachie, Technical Business Developer, AWS
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Get the Most Bang for Your Buck with #EC2 #WINNING
Similar to Get the Most Bang for Your Buck with #EC2 #WINNING (20)
More from Amazon Web Services
More from Amazon Web Services (20)
Recently uploaded
Recently uploaded (13)
Get the Most Bang for Your Buck with #EC2 #WINNING
- 1. Š 2016, Amazon Web Services, Inc. or its Affiliates. All rights reservedŠ 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved Get the Most Bang for Your Buck with #EC2 #Winning Boyd McGeachie, Product Manager
- 2. Amazon EC2 purchasing options On-Demand Pay for compute capacity by the hour with no long-term commitments For spiky workloads, or to define needs Reserved Make a 1 or 3 Year commitment and receive a significant discount over On-Demand For committed or baseline utilization Spot Pay market price for unused compute capacity at a steep discount over On-Demand For fault tolerant, time-insensitive or transient workloads
- 3. Pillars of performance and cost-optimization Right sizing Purchasing options Increase elasticity Measure, monitor, & improve
- 4. Right sizing Right sizing ⢠Selecting the cheapest instance available while meeting performance requirements ⢠Looks at CPU, RAM, storage, and network utilization to identify potential instances that can be downsized
- 5. Increase elasticity Turn off non-production instances ⢠Look for dev/test, non-prod instances that are running always-on and turn off Automatically scale production ⢠Use Auto Scaling to scale in and out based on demand and usage (for example, spikes)
- 6. Measure, monitor, and improve: Uncover the cost-optimization opportunities Auto-tag resources Identify always-on non-prod Identify instances to downsize Recommend Reserved Instances to purchase Dashboard our status Report on savings
- 7. AWS pricing principles Pay as you go Pay less when you reserve Pay less when AWS grows No up-front investment
- 8. We completed the equivalent of thirty-nine years of computational chemistry in just under 9 hours for a cost of around $4200. Steve Litster Global Head of Scientific Computing, Novartis â â Novartis: Acceleration of pre-clinical R&D ⢠Existing infrastructure to screen 10 million compounds in a computational model not available ⢠New infrastructure would have cost approximately $40 million to build Novartis used AWS for HPC computational chemistry
- 9. Amazon EC2 purchasing options On-Demand Reserved Spot
- 10. EC2 On-Demand pricing Short-term, spiky and unpredictable Low cost and flexible Develop and test
- 11. EC2 Reserved pricing Upfront payments to reduce costs Steady state Optional capacity reservation New
- 12. Characteristic Standard Payment No upfront Partial upfront All upfront Commitment 1 year 3 year Sellable on RI Marketplace Yes Change Availability Zone, instance size (Linux), networking type Yes Console and API: ModifyReservedInstances Change instance families, operating system, and tenancy No Savings* Up to 75% Standard Reserved Instance details * Dependent on AWS service, size/type, and region
- 13. 2007 2008 2009 2010 2011 2012-2013 2014 m1.xlarge m1.large m1.small m2.2xlarge m2.4xlarge c1.medium c1.xlarge m1.xlarge m1.large m1.small cc2.8xlarge cc1.4xlarge cg1.4xlarge t1.micro m2.xlarge m2.2xlarge m2.4xlarge c1.medium c1.xlarge m1.xlarge m1.large m1.small c3.large c3.xlarge c3.2xlarge c3.4xlarge c3.8xlarge cr1.8xlarge hs1.8xlarge m3.xlarge m3.2xlarge hi1.4xlarge m1.medium cc2.8xlarge cc1.4xlarge cg1.4xlarge t1.micro m2.xlarge m2.2xlarge m2.4xlarge c1.medium c1.xlarge m1.xlarge m1.large m1.small cc1.4xlarge cg1.4xlarge t1.micro m2.xlarge m2.2xlarge m2.4xlarge c1.medium c1.xlarge m1.xlarge m1.large m1.small c3.large c3.xlarge c3.2xlarge c3.4xlarge c3.8xlarge hs1.8xlarge m3.xlarge m3.2xlarge hi1.4xlarge m1.medium cc2.8xlarge cc1.4xlarge cg1.4xlarge t1.micro m2.xlarge m2.2xlarge m2.4xlarge c1.medium c1.xlarge m1.xlarge m1.large m1.small c1.medium c1.xlarge m1.xlarge m1.large m1.small new existing g2.2xlarge m3.medium m3.large i2.large i2.xlarge i2.4xlarge i2.8xlarge r3.large r3.xlarge r3.2xlarge r3.4xlarge r3.8xlarge t2.micro t2.small t2.medium c4.large c4.xlarge c4.2xlarge c4.4xlarge c4.8xlarge Increasing customer choice⌠2010 latest 2015 c3.large c3.xlarge c3.2xlarge c3.4xlarge c3.8xlarge hs1.8xlarge m3.xlarge m3.2xlarge hi1.4xlarge m1.medium cc2.8xlarge cc1.4xlarge cg1.4xlarge t1.micro m2.xlarge m2.2xlarge m2.4xlarge c1.medium c1.xlarge m1.xlarge m1.large m1.small g2.2xlarge m3.medium m3.large i2.large i2.xlarge i2.4xlarge i2.8xlarge r3.large r3.xlarge r3.2xlarge r3.4xlarge r3.8xlarge t2.micro t2.small t2.medium c4.large c4.xlarge c4.2xlarge c4.4xlarge c4.8xlarge d2.xlarge d2.2xlarge d2.4xlarge d2.8xlarge m4.large m4.xlarge m4.2xlarge m4.4xlarge m4.10xlarge t2.large As Technology AdvancesâŚ
- 14. âŚConvert Your Reserved Instances The Convertible Reserved Instance is a new type of Reserved Instance that can be exchanged during the 3 year term for new Convertible Reserved Instances of equal or greater value. The new Convertible Reserved Instances can correspond to a different instance family or a new price, instance size, platform, or tenancy instance optimized instance
- 15. Convertible Reserved Instance details * Dependent on AWS service, size/type, and region Characteristic Standard Convertible Payment No upfront Partial upfront All upfront No upfront Partial upfront All upfront Commitment 1 year 3 year 3 year Sellable on RI Marketplace Yes Coming soon Change Availability Zone, instance size (Linux), networking type Yes Console and API: ModifyReservedInstances Yes Console and API: ExchangeReservedInstances Change instance families, operating system, and tenancy No Yes Savings* Up to 75% Up to 45%
- 16. EC2 Spot pricing Users with urgent computing needs or large amounts of additional capacity Time or instance flexible Experiment and/or build cost-sensitive businesses
- 17. Spot Instance details Options ⢠Spot Fleet to maintain instance availability ⢠Spot block durations (1-6 hours) for workloads that must run continuously Commitment level ⢠None * Compared to On-Demand price based on specific EC2 instance type, region, and Availability Zone
- 18. Spot rules Markets where the price of compute changes based on supply and demand Youâll never pay more than your bid 50% bid of OD 75% bid of OD 25% bid of OD You pay the market price 87% discount!
- 19. Which EC2 purchasing model is right for me?
- 20. Have a balanced meal! Why choose just one business model?
- 21. Use a combination of all three! 1. Use Reserved Instances for known/steady-state workloads 2. Set up multiple Auto Scaling groups 3. Scale using Spot, On-Demand, or both 0 2 4 6 8 10 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 /Spot On-Demand Spot Reserved
- 22. Examples
- 23. Example: Three-tier web app
- 24. Tagging is essential! ⢠How do we explain the costs? ⢠How do we allocate the charges to the right team? ⢠How do we save money?
- 26. Stateless Scale based on demand Web tier 0 5 10 15 20 25 30 35 40 0 2 4 6 8 10 12 2 4 6 8 10 Web servers Reserved Spot On-Demand 0 50 100 150 200 250 300 350 400 0 2 4 6 8 10 12 2 4 6 8 10 Web traffic
- 27. App tier Stateful Scale based on demand 0 10 20 30 40 50 0 2 4 6 8 10 12 2 4 6 8 10 App servers Reserved On-Demand Spot block 0 100 200 300 400 500 0 2 4 6 8 10 12 2 4 6 8 10 App requests
- 28. Database Tier Highly stateful Static at peak load 0 0.5 1 1.5 2 2.5 3 3.5 0 2 4 6 8 10 12 2 4 6 8 10 Database servers Reserved On-Demand Spot 0 100 200 300 400 500 600 700 800 900 0 2 4 6 8 10 12 2 4 6 8 10 Database requests
- 29. Summary: Three-tier web app 0 10 20 30 40 50 60 70 80 90 0 2 4 6 8 10 12 2 4 6 8 10 Three-tier application servers Reserved On-Demand Spot Summary Have a balanced meal! Across the three tiers, our meal consists of: ⢠Spot 13% ⢠On-Demand 11% ⢠Reserved 76% Remember! âNo server is easier to manage than no serverâ - Werner Vogels, CTO, Amazon.com
- 30. Ubisoft uses AWS to develop and launch social games quickly ⢠Ubisoft is a Paris-based gaming company, and creator of popular gaming titles, including Assassins Creed, Far Cry, and Just Dance ⢠Moving games to social and mobile platforms required capacity to scale fast; using a traditional environment would be an extensive and costly investment ⢠Using the AWS Cloud to optimize games at the application, caching, and data layers, improving the user experience â â By using the AWS cloud we were able to launch 10 social games within 18 months. Lenin Gali Senior Director, Ubisoft
- 32. Time Typical server utilization rates are low due to need to deploy for peak needs⌠The old way: Low utilization, high costs
- 33. Time Higher grid utilization rates result in hidden costs: longer queue wait times and delayed results The old way: Managing utilization with grids
- 34. 0 20 40 60 80 100 120 140 160 3 year Reserved Instances ? The old way: In the cloud!
- 35. Higher utilization can reduce IT spending⌠0% 20% 40% 60% 80% 100% Grid Utilization The world as seen by central IT
- 36. -600% -500% -400% -300% -200% -100% 0% 100% 0 200 400 600 800 1000 1200 1400 Jobs in the Queue Grid Utilization But higher utilization also creates IT constraints⌠Every job in the queue represents business impact But Grid Utilization looks great! The world as seen by the business
- 37. Reduced Time Project Acceleration Scale higher to reduce time to results: shorter wait times, greater agility, faster innovation cycles The cloud way: Scalability when needed
- 38. ? The new way: In the cloud! 0 100 200 300 400 500 600 1 2 3 4 5 6 7 8 9 10 11 12 Optimizing for cost and business results Spot Spot block On-Demand 3 year Reserved Instances
- 39. 0 100 200 300 400 500 600 1 2 3 4 5 6 7 8 9 10 11 12 Going a step further with Spot blocks! Spot Spot block On-Demand 3 year Reserved Instances The new way: In the cloud! ?
- 40. âWe constantly understate what our capabilities are to solve problems. The biggest constraint is never the constraint of time or money, itâs generally the constraint of thought.â â Jeff Smith, CEO, Suncorp Business Services Founded: 1996 ⢠Employees: 15,000+ ⢠Headquarters: Brisbane, Australia Accelerating transformation
- 41. EC2 purchasing options by industry
- 42. Web scale (e.g. Adtech) company Enterprise SaaS company Purchasing model by industry
- 43. Onboarding enterprise Gaming company Purchasing model by industry
- 44. Technology companyScientific research Purchasing model by industry
- 45. Different purchasing options in a single company Data science New app development Test and development Internal IT
- 46. Letâs recap ďź Remember the pillars of optimization ďź Right-sizing ďź Increase elasticity (turn stuff off!) ďź Measure, monitor, and improve ďź Use tags to understand your services ďź There are 3 core purchasing options â have a balanced meal ďź Architect your workloads with performance and cost in mind
- 47. Summary Freedom to build unfettered Freedom to get real value from data Freedom to say yes AWS is more cost-effective in both short-term and long-term than on-premises environments. By leveraging the EC2 purchase models, you gain theâŚ
- 48. Š 2016, Amazon Web Services, Inc. or its Affiliates. All rights reservedŠ 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved aws.amazon.com/activate Everything and Anything Startups Need to Get Started on AWS
Editor's Notes
- Today weâre here to discuss the AWS EC2 Purchasing Options, how to leverage them to get the highest availability and performance while minimizing costs. AWS offers three core Purchasing Options On-Demand, Reserved, Spot instances. [read slide]. Each purchasing model launches the same underlying EC2.
- There are four consistent, heavy hitting drivers of cost optimization â Instance right sizing, Purchasing reserved or dedicated instances, and using Spot Increasing instance elasticity. When combined with the ability to measure and monitor, we come up with the four pillars of cost optimization. Today weâre focusing just on the Purchasing Options, but the remaining three are important so lets do a quick refresher.
- Â AWS offers roughly 60 instance types and sizes (you saw just a few of the available families earlier), which is great for customers because it allows users to select the best fit instance for their workload. It can also be a bit daunting, knowing where to start and what the best instance is from a cost perspective â not just technical. We define right sizing as the cheapest instance while meeting performance requirements. Itâs the process of look at deployed resources and looking for opportunities to downsize when possible. Testing is cheap, one can easily provision any type and size of instance and to test their application on, use this advantage (you can test using Spot to do it even cheaper!).
- Do keep in mind when we talk about scaling weâve largely focused here on scaling down. When running inside your own environment you need to guestimate peak demand then provision for that. Within the cloud you no longer need to guess, and should only run at peak during your peak demand periods. What this results in when we talk about scalability is returning capacity you no longer need and not paying for it. Elasticity is using an instance when you need it, but turning it off when you donât. Itâs one of the most central tenants of the cloud, but often times, we see customers go through a learning process for figuring out how to operationalize this in order to drive cost savings. So lets start with a very simple example â if your developers only work from 8-5, turn the instances off from 5-8! This can save you over 50% with almost no technical consideration needed! As a slightly more complicated example for production workloads, getting more precise and granular with auto scaling is going to help ensure that youâre able to take advantage of horizontal scaling in order to meet peak capacity needs â while not paying for peak capacity.
- In almost any environment you must measure, monitor and seek to improve performance. However, the beautiful thing about leveraging the cloud is as you identify opportunities to improve you (right sizing, scaling down etc.) you can immediately capitalize on it to improve performance, availability and/or cost. Is essential to provide information about what resources are being used by who and for what purpose. You can use tags as an example to identify always on non-prod and scale them down, or move them to Spot! AWS even provides recommendations through Trusted Advisor and there are a number of partners who have good tooling here as well (CloudAbility, Cloud Checkr, Cloudyn, and Cloud Health being a few of them).
- You can react and reap reward rapidly because of the AWS pricing principles. Our pricing principles are designed around the you the customer, understanding and using these will give you confidence AWS has your workload and needs covered. Since its inception AWS has believed that to innovate you need to reduce the barrier to entry and cost of failure. EC2 enables this by enabling no upfront investment, pay as you go but if an innovation is successful you can reserve to pay less. As as we continue to innovate on behalf of our customers we pass those savings on to customers in the form of over 50 price reductions since 2006.
- Note to speaker: See case study online: http://aws.amazon.com/solutions/case-studies/novartis/ Scientists at Novartis had identified a target molecule and needed to screen 10 million compounds against it in a computational model Existing infrastructure was not available New infrastructure would have cost approximately $40 million to build Novartis built a virtual high-performance computing data center in the cloud to run the experiments Dramatically reduced time to science â able to receive an answer in a fraction of the time at a fraction of the cost
- Ok now into the meat of the discussion!
- Users that want the low cost and flexibility of Amazon EC2 without any up-front payment or long-term commitment Applications being developed or tested on Amazon EC2 for the first time Applications with short term, spiky, or unpredictable workloads that cannot be interrupted
- Applications with steady state or predictable usage Applications that require reserved capacity Users able to make upfront payments to reduce their total computing costs even further Sept 2016: Regional Benefit -Many customers have told us that the reserved pricing discount is more important than the capacity reservation, and that they would be willing to trade it for increased flexibility. You can choose to waive the capacity reservation associated with Standard RI, run your instance in any AZ in the Region, and have your RI discount automatically applied. This means that you no longer have to worry about the AZ alignment between your RIs and instances. The regional benefit is offered without a capacity reservation since the selection of an AZ is required to reserve capacity. If you need a capacity reservation, the option to reserve capacity and apply your RI to a specific AZ is still available. Standard RI: The Reservation Benefit: This benefit only exists for the account that the RI âlivesâ in as it is based on the specific account and that accountâs AZ mapping to a specific physical location The Regional Benefit: This regional benefit allows you to run instances in any AZ in an AWS Region and AWS will apply the reservation pricing benefit to your instances automatically.
- You can save up to 75% off the On-Demand rate. You can choose between three payment options when you purchase a Standard Reserved Instance. With the All Upfront option, you pay for the entire Reserved Instance with one upfront payment. This option provides you with the largest discount compared to On-Demand Instance pricing. With the Partial Upfront option, you make a low upfront payment and are then charged a discounted hourly rate for the instance for the duration of the Reserved Instance term. The No Upfront option does not require any upfront payment and provides a discounted hourly rate for the duration of the term. And the longer you commit, the more you can save. When you define an Availability Zone, you also get the benefit of capacity reservation. This can provide you additional confidence in your ability to launch the number of instances you have reserved when you need them. Now if your needs change after you have purchased a Reserved Instance, you can request to move your Reserved Instance to another Availability Zone within the same region, change its Network Platform or, for Linux/UNIX RIs, modify the instance type of your reservation to another type in the same instance family, at no additional cost. The other option is to sell your unneeded RIâs on the RI Marketplace! Now with a standard RI, youâve defined the instance family, OS, tenancy, and payment option you want to use to get the discounted price. Deciding to lock in for a 3 year commitment with todayâs technology can be a hard decision.
- As technology improves, we want to ensure customer are able to benefit from improvements in CPU, SSD, and other components. We do this through our current generation instance types and families. From 2007 to today, we have grown are offering to from 3 to over 50 instance types, and moved from 1 to 7 family types. Todayâs families are General-purpose: M1, M3 , M4, T2 Compute-optimized: C1, CC2, C3, C4 Memory-optimized: M2, CR1, R3, X1 Dense-storage: HS1, D2 I/O-optimized: HI1, I2 GPU: CG1, G2 Micro: T1, T2 And more importantly, weâve had over 50 price changes since 2006, passing the benefits on to our customers. And customer of RIs have can also benefit with a new RI offering⌠<next slide> ----------------------------- Background --------------- Here are some highlights of things weâve launched in the past few months: D2 is our newest and latest instance. It is powered by 2.4 GHz Intel Xeon E5 2676v3 (Haswell) processors; improves on HS1 instances by providing additional compute power, more memory, additional instance sizes, and Enhanced Networking. D2 instances are available in four instance sizes, with 6 TB, 12 TB, 24 TB, and 48 TB storage options. C4 â 2.9 GHz Intel Xeon E5-2666v3 (Haswell â AVX2) CPUs T2 is our lowest cost general purpose instance at $0.013 per our On-Demand, thatâs around $9.50 per month, and can drop to $4.20 per month with 3 Year RIs R3 is our current generation memory optimized instance with enhanced networking and memory up to 244 GiB I2 is the current generation storage optimized instance offering up to 350,000+ random read IOPS (4k) G2 with NVIDIA GK104 GPUs
- Convertible RIs is a new offering that provides flexibility to you to trade up for your benefit. <Read Slide> Let me give you some examples of how you can convert you RIs. With a Convertible Reserved Instances you can: Convert to a new instance family e.g. R3 to C3 to T2 to M4 Convert to a new instance price e.g. if AWS reduces the public rate of your instances Convert to a new operating system e.g. Windows to Linux Convert tenancy e.g. from Dedicated Instances to normal Convert to a higher discount tier e.g. No Upfront to Partial Upfront Leverage the new Regional benefit
- Convertible Reserved Instances provide a discount (up to 45% off On-Demand) and the capability to change the attributes of the Reserved Instance as long as the exchange results in the creation of Reserved Instances of equal or greater value. Like Standard Reserved Instances, Convertible Reserved Instances are best suited for steady-state usage.Â
- Applications that have flexible start and end times Experiments that can only be conducted at very low compute prices (Brookhaven and Fermi â analyzing the origins of our universe). Or business that need extremely low infrastructure costs to achieve profitability such as Adtech. Users with urgent computing needs or large amounts of additional capacity
- Spot Instances provide the ability for customers to purchase compute capacity with no upfront commitment and at hourly rates usually lower than the On-Demand rate, often as much as 90% cheaper - for those wondering what is a 90% discount? It is about 1c per core hour. Ask yourself what could your best people do, or how well could your application perform with a 10,000 core data center that costs just $100 per hour..
- So the spot rules are actually pretty simple. There is a market determined pricing mechanism, that is often as much as 90% off the On-Demand price. You never pay more than your bid, in fact youâll often pay significantly less than your bid! Should the market price exceed your bid, we give you 2 minutes to wrap up your work! Here is a quick example of the impact of bidding on interruptions and price. 25% you kept your instance for almost 7 days, being impacted during a few short periods. However, you only paid the market price which was 86% off, just less than 20c per hour during the last week, only 14% of the OD price. At 50% you would have been interrupted just once, for a very short period of time during the sixth day. Youâre average discount during the week is 85% just 21c per hour, paying just 15% of OD. At 75% you would not once have been interrupted, achieving an average discount of 85% just 21c an hour, again paying just 15% of OD. So a simple tip for getting started with Spot is bid the on-demand price and youâll still only pay the market rate often just 10% of the on-demand price! If youâre using Spot fleet it will automagically handle the re-provisioning of your capacity!
- Picking just one EC2 purchasing model is the wrong way to ask the question. [click] Its like picking a single type of food and eating only that for the rest of your life. You should have a balanced meal! You might be wondering, well which is which? Ask yourself which is your favorite, that is Spot! Pause for laugh.
- So having a balanced meal means - Use Reserved Instances for known/steady-state workloads Set-up multiple Scaling groups Scale using Spot, On-Demand or both
- Most web applications seek to optimize on three angles, often in this this order of importance - High Availability. In the modern world we expect services to be available when we need them. No excuses. Performance. An old Amazon.com piece of research found a 1 second performance delay could reduce revenue $1.6B per annum! Finally, having satisfied availability and performance we aim to achieve both at the lowest possible cost. Just to explain the core concepts of what is going on in this picture. HTTP requests are first handled by the ELB, which automatically distributes incoming application traffic among multiple Amazon EC2 instances across multiple AZ's. Web servers and applications are deployed on Amazon EC2 instances. Most organizations will select an AMI and then customize it to their needs, creating a custom AMI or using technology such as Docker, Chef or Puppet to deploy their software on the instance. These EC2 instances are deployed into an Auto Scaling Group that automatically adjusts your capacity up or down according to conditions you define. To provide high availability, the relational database that contains application data is hosted redundantly on a Multi-AZ deployment using Amazon RDS.
- To help you manage your instances, images, and other Amazon EC2 resources, you can assign your own metadata to each resource in the form of tags Tagging accurately, enables us to understand different components of our compute resources and therefore how to best optimize. It also allows us to report back to the business costs. You can have up to 10 tags per ec2 instance!
- Tagging instances enables us to turn a random sequence of numbers into actionable information. This is how we will have a clear understanding of what are Web servers, app servers and Database servers. We can take it a step further and know where theyâre test, QA or prod nodes. Because we can add 10 tags we might use one of them to define an internal cost center, one for the individual user launching capacity.. There are many options. But tagging is core. Because weâre smart and have used tagging now we can dive into how to optimize based on the nature of the application. Because how we optimize for the web tier might be different than the app tier, and is almost certainly different from the database tier! Lets dig in.
- In this well designed application the web tier is entirely stateless, enabling a highly available deployment where weâre treating EC2 instances as cattle not pets, any individual server coming in or out of service does not have any negative impact on customer experience. It enables a fast and powerful response to customer demand, no longer do we need to âguestimateâ peak load and deploy capacity to meet it. It also allows us to make aggressive use of Spot instances, while achieving these goals to deliver an incredibly low TCO.
- Here weâre assuming their app tier is scalable, but âstatefulâ. Even in some well designed applications there may be a reason to treat the application tier as stateful. E.g. if youâre keeping a local cache of results to improve responsiveness for recurring/common requests. In this example weâre going to run a higher percentage of reserved instances, and largely use On-Demand instances to deal with peak traffic during the day. However, in a pattern where we have short term peaks it is an opportunity to use Spot block duration instances, which come at a 30-50% discount over on-demand without the risk of interruption for up to 6 hours.
- Iâm the Spot guy, so Iâm only going to say this once. You do not run your databases on Spot. You run your databases using Reserved Instances. However, there is still an opportunity to leverage the dynamic nature of Spot. What we often see customers struggling with on premise is managing the reporting process, whether that be daily, weekly or monthly. Unfortunately what we often see is customers having to run an oversized database just to deal with reporting needed, while ensuring it doesnât impact customer performance (meaning having to run reports at odd hours, delaying adhoc reporting or accepting degraded customer performance). Because there is no long term commitment using On-Demand you can now simply take a backup/snapshot of your database and spin it up on independent infrastructure as you need it and turn it back off when youâre done.
- While weâve treated each tier separately we are likely using one of our tags common across all 3. This is our âwebsiteâ tag. As we drill down on the website tag we recognize weâre having a balanced meal! Across the three tiers our meal consist of Spot 13% On-Demand 11% Reserved 76% Remember, there may be an opportunity to not run servers at all. The easiest server to manage is no server at all! Whether that being moving simple functions/cron to Lambda, removing the need for queuing servers via SQS, using SES instead of running mail servers. The list goes on. Ask yourself, is this something we want to manage and maintain? Is there a service for this?
- âInvention requires two things: 1. The ability to try a lot of experiments, and 2. not having to live with the collateral damage of failed experiments.â â Andy Jassy Zynga chat.
- Grid is broad. Grid computing is the collection of computer resources from multiple locations to reach a common goal.. You can think of these same principles as applying to many different type of batch processing, from schedulers through to Hadoop and/or Spark. There are many different patterns around grid, but a few commonalities. Youâre going to have files, whether its lots of small files, a few large or some combination stored in either object storage (such as S3) if the application can use HTTP or on a service acting as a FUSE layer if the service requires POSIX-style file system (Such as EFS, or Luster). You grid of computers, EC2, will then process that data using local scratch (many of our instances have local attached ephemeral storage, or you can attach EBS volumes!) or the file systems I just mentioned for temp files. Finally when done, ideally your putting output files into S3 where there is 11 9âs of durability and can easily grant access to internal or external users in a secure and scalable manor.
- In order to keep up with the demand for computing youâre going to be buying computers ahead of demand. Naturally this creates low utilization and high costs. So what you see here on the screen is not what most users actually experience. How do you calculate ROI on an experiment with unknown outcomes? For those of you whoâve read the innovators dilemma this might hit home, invest in an idea with a completely unknown ROI. Internal IT starts servicing only the large profitable business, neglecting the new opportunities to innovate and improve or deliver entirely new services. Therefore what we often see is..
- This is the reality. The vast majority, if not all internal users will be constrained. Not delivering compute dynamically based on demand, but rather ensuring high levels of resource utilization. Can you imagine being the PhD at Novartis who has a wild idea to cure cancer but you donât know if it will work.. And you need to make the case to invest in a $40M datacenter before working out if its viable? There is a hidden cost here, but first.. Could we do this in the cloud?
- Well of course you can do the same thing in the cloud. Buy 3 year reserved instances and save up to 75% while ensuring you have high utilization. But as Iâve already mentioned, there are some significant hidden costs here.
- Yay weâre crushing it! Using our data center close to 100% of the time!
- Create a new grid with the blue line up the top and the red line banging against it. Conflicting goals Grid users seek fastest possible time-to-results Grid workloads are not steady-state IT support team seeks highest possible utilization Result: The job queue becomes the capacity buffer Job completion times are hard to predict Users are frustrated and run fewer jobs Innovation is throttled by IT resources
- Innovation is no longer throttled by IT resources. Your base use is covered by Reserved Instances to service the mature (often profitable) parts of the business. Leveraging On-Demand for some of the workloads that do not have fault tolerance then enabling access to all those crying out for resources to Spot. Youâd be surprised how high the ROI is when an engineer will make their code fault tolerant when it means getting access to 10,000 core data center for just $100 per hour.
- You might take this a step further and identify the jobs using OD that live for <=6 hours. Those can immediately move to Spot block to save even more! The flexibility to operate the way your business operates. Youâre no longer forcing a business to work in a capital intensive way, youâre responding to demand of your uses and again removing the impediment to innovation. As Andy Jassy the CEO of AWS has said - âInvention requires two things: 1. The ability to try a lot of experiments, and 2. not having to live with the collateral damage of failed experiments.â
- I love this quote because it speaks to how the clouds flexibility is enabling freedom of thought to transform into action. When leveraging the Cloud effectively youâre no longer constrained by your infrastructure investments, you donât need to question your ability to solve the hardest challenges. When using the cloud effectively youâre generally only constrained by your thoughts. Suncorp Group is a multi-billion dollar, diversified Australian financial services company and runs a complex and expensive IT environment to support 14 brands and 4 lines of business in 5 countries. The organization embraces a culture of innovation and takes pride in their talent, what they consider their primary business enabler and competitive advantage.
- I call Adtech an inherently web scale business because thatâs exactly what these companies are doing. Real-time bidding, dynamically to buy and sell ads per-impression on the internet. Iâll give you a little background here, a typical transaction begins with a user visiting a website. This triggers a bid request that can include various pieces of data. The an ad exchange where multiple advertisers automatically submit bids in real time to place their ads. The impression goes to the highest bidder and their ad is served on the page. Typically this whole process needs to be done within 100 milliseconds from the moment the ad exchange received the request. Many adtech companies are doing this process over 50 billion times a day. Adtech companies scale up and down based on demand and have therefore often designed highly resilient architectures that can seamlessly hide individual instance failure. Because each transaction must be processed within 100ms the Spot 2 minute warning is a lifetime for these companies which is why we see such a high %. The exact inverse is what we might see in an enterprise SaaS company that long ago built a monolithic application. As the user interface and data access are combined into a single program on a single platform it is not easy to mask instance failure and scale dynamically during the day. This means deployments tend to be very static, this lends the model very well to purchasing reserved instances. Even better a deployment might be directly related to a customer contract given easy predictability to purchase 3 year reserved instances and save up to 75%! Now of course we see some on-demand use, likely internal dev-test or PoC with new customers!
- When we look at a traditional enterpriseâs journey to the cloud it often begins as teams/businesses individually begin leveraging cloud to rapidly prototype and deliver new technologies or revenue streams to their business. For the same reasons as my earlier quote from Andy Jassy, innovation requires lots of experimentation and not having to deal with fallout of the failed experiments On-Demand is where they begin. As these enterprises begin thinking beyond a constrained environment, pushing the boundaries of innovation they will find themselves leveraging compute capacity from the cloud on demand. For those âexperimentsâ that prove themselves successful the enterprises reserve capacity and get up to 75% discounts. As they recognize the flexibility and agility the cloud delivers the enterprise will migrate many of those monolithic applications weâve just spoken about to the cloud, and similarly after they reach steady state reserve. If we look at a specific type of enterprise, a gaming enterprise as example the patterns become even clearer. Enterprise game companies are in the business of creating, building and launching fantastic experiences for gamers. The compute pattern leading up to and through a launch is very predictable, in particular the public beta and launch is clear here. However, despite a knowledge of when youâre going to need capacity you donât necessary know how much or for how long. What we can see here is a company with many successful games (and no doubt standard backend company infrastructure) who launches beta small increase and a huge launch! But we all know the peaks of launch often donât run long term so they come off a peak and increase their reserve capacity. As the Spot guy I have to assume his gaming company doesnât manage a lot of their own analytics so theyâre not using Spot a lot!!
- To round this out we have an entirely different type of company, a company focused on pushing the boundaries of scientific research. This graph is actually a little misleading, one might assume they donât use a lot of compute over a year. However, that is just because when doing computational science the multiple off base usage can be huge! What is already a lot of base capacity, and running on-premise might be the limiting factor on experimentation or innovation, may be less than 1/20th of whatâs needed during those weeks you push the boundaries of science to discover.. Finally, what about a large technology company? The type of very large, multi-business unit, 10âs of thousand employee organization. Theyâve been running their common core business applications such as HR SAP, SharePoint, CRMs, exchange etc. for years leveraging reserved instances. Theyâve been testing new versions of the environment using On-demand servers. However, theyâre also building new lines of business based on IoT, discovering decision making information from their data via new big data platforms and building the next generation of their platform via electronic design automation leveraging On-Demand and Spot instances.
- And thatâs exactly what we see within every large scale organizations. A single company can have different units within a single company. Whether it be the data science or quant team, discovering new opportunities to optimize supply chain using 1c per core hour compute via EC2 Spot instances. There are teams building net new applications trying to build the next million (or billion) dollar business unit, here is one that may have been tracking costing just a $100 a week but then one new line takes off rapidly and capacity dynamically scales to meet customer demand. Of course there is the traditional IT arm, delivering internal services like HR systems making heavy use of reserved instances. Finally test and development as you got through the process to deliver new versions, making use of Spot, On-Demand and reserved instances.
- Remember the pillars of optimization Right Sizing Increase elasticity (turn stuff off!) Measure, Monitor and Improve Use Tags to understand your services. You donât need to hire people to do this. There are 3 core purchasing options â have a balanced meal! Architect Your Workloads with Performance and Cost in Mind As you move away from monolithic applications to service oriented architectures youâll find yourself with more opportunities to use Spot.
- AWS is more cost-effective than on-premises environments in both short-term and long-term and leveraging the EC2 purchase models enables Freedom to build unfettered Freedom to get real value from data Freedom to say Yes