Architecting for scale - dynamic infrastructure and the cloud
•Als PPTX, PDF herunterladen•
0 gefällt mir•566 views
Architecting for scale - dynamic infrastructure and the cloud
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Architecting for scale - dynamic infrastructure and the cloud
Ähnlich wie Architecting for scale - dynamic infrastructure and the cloud (20)
Mehr von Lee Atchison
Mehr von Lee Atchison (9)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Architecting for scale - dynamic infrastructure and the cloud
- 1. ©2008–17 New Relic, Inc. All rights reserved#FutureStack Dynamic Infrastructure and the Cloud Lee Atchison ∙ Senior Director Strategic Architecture at New Relic, Inc. leeatchison@leeatchison Architecting for Scale
- 2. ©2008–17 New Relic, Inc. All rights reserved#FutureStack What Is a Dynamic Infrastructure? Use Only the Resources you need Allocate / de-allocate resources on the fly Resource allocation is an integral part of your application architecture An Application Architecture Where:
- 3. ©2008–17 New Relic, Inc. All rights reserved#FutureStack Dynamic Applications Resources are: Application in charge: Allocated Application is aware of and is controlling traditional OPs resources Consumed De-allocated
- 4. ©2008–17 New Relic, Inc. All rights reserved#FutureStack Dynamic Infrastructure Example… Docker Container Age (Count vs. Hours) 1 Hour 200 days 833 days
- 5. ©2008–17 New Relic, Inc. All rights reserved#FutureStack Dynamic Infrastructure Example… Docker Container Age (by Minute and Hour) 1,200,000 11% under one minute Container age (minutes)
- 6. ©2008–17 New Relic, Inc. All rights reserved#FutureStack Dynamic Infrastructure -> Dynamic Cloud Dynamic Cloud is about scaling and availability EC2 Auto Scaling Mobile / IoT Dynamic routing Load balancing Queues and notifications Docker Cloud Technologies Enable Dynamic Infrastructure
- 7. ©2008–17 New Relic, Inc. All rights reserved#FutureStack Changing World Ops Previous - STATIC World
- 8. ©2008–17 New Relic, Inc. All rights reserved#FutureStack Changing World Dev Now - DYNAMIC World Ops Ops Previous - STATIC World
- 9. ©2008–17 New Relic, Inc. All rights reserved#FutureStack Leveraging the Cloud for Dynamic, Highly Scaled Applications ©2008–17 New Relic, Inc. All rights reserved#FutureStack
- 10. ©2008–17 New Relic, Inc. All rights reserved#FutureStack Experiment Cloud Policies Enable Servers, Enable SaaS Enable Value-Added Services Enable Unique Services Mandate Cloud Usage Progressions in Cloud Adoption… Maturity Levels: Standard steps most companies follow ©2008–17 New Relic, Inc. All rights reserved#FutureStack
- 11. ©2008–17 New Relic, Inc. All rights reserved#FutureStack Experiment Progressions in Cloud Adoption ©2008–17 New Relic, Inc. All rights reserved#FutureStack
- 12. ©2008–17 New Relic, Inc. All rights reserved#FutureStack Enterprise IT Cloud Adoption Strategy Experiment • Non-evasive, safe technologies – S3 – Perhaps: CloudFront, SQS, SES • Stay away from EC2/Servers • Security: Easy as one-offs • No “Policies” implemented yet • “Just seeing what this is all about” Progressions in Cloud Adoption What is this cloud thing?
- 13. Experiment Cloud Policies Progressions in Cloud Adoption ©2008–17 New Relic, Inc. All rights reserved#FutureStack
- 14. ©2008–17 New Relic, Inc. All rights reserved#FutureStack Enterprise IT Cloud Adoption Strategy Cloud Policies • IAM (Credentials) • VPC (Secure network) • AWS Direct Connect (just another data center) • Cloud policies begin to be formed • All parts of the company are now involved • Critical evolution point Progressions in Cloud Adoption Can we trust the cloud?
- 15. Experiment Cloud Policies Enable Servers, Enable SaaS Progressions in Cloud Adoption ©2008–17 New Relic, Inc. All rights reserved#FutureStack
- 16. ©2008–17 New Relic, Inc. All rights reserved#FutureStack Enterprise IT Cloud Adoption Strategy Enable Servers, Enable SaaS • EC2 – Basic “data center migration” – Just another server type available… • Multiple AZs/Regions – Part of multi-datacenter resiliency strategy • Independently: SaaS usage increases – Non-critical or internal uses first Progressions in Cloud Adoption The cloud seems to work pretty well…
- 17. Experiment Cloud Policies Enable Servers, Enable SaaS Enable Value-Added Services Progressions in Cloud Adoption ©2008–17 New Relic, Inc. All rights reserved#FutureStack
- 18. ©2008–17 New Relic, Inc. All rights reserved#FutureStack Enterprise IT Cloud Adoption Strategy Enable Value-Added Services • Managed Databases – RDS, Aurora • Other Managed Services – Elastic Beanstalk, SES, SQS, ElasticSearch Progressions in Cloud Adoption Dynamic Cloud becomes a thing…
- 19. Experiment Cloud Policies Enable Servers, Enable SaaS Enable Value-Added Services Enable Unique Services Progressions in Cloud Adoption ©2008–17 New Relic, Inc. All rights reserved#FutureStack
- 20. ©2008–17 New Relic, Inc. All rights reserved#FutureStack Enterprise IT Cloud Adoption Strategy Enable Unique Services • High value, Cloud-specific services – Lambda, Kinesis – DynamoDB – SWF, Elastic Transcoder – Redshift • Point of commitment... ... dependent on cloud Progressions in Cloud Adoption Dynamic Cloud is deeply ingrained…
- 21. Experiment Cloud Policies Enable Servers, Enable SaaS Enable Value-Added Services Enable Unique Services Mandate Cloud Usage Progressions in Cloud Adoption ©2008–17 New Relic, Inc. All rights reserved#FutureStack
- 22. ©2008–17 New Relic, Inc. All rights reserved#FutureStack Enterprise IT Cloud Adoption Strategy Mandate Cloud Usage • Cloud as a data center replacement • Company is now “all in” with cloud • Becoming more commonplace Progressions in Cloud Adoption Why do we need our own data centers?
- 23. Experiment Cloud Policies Enable Servers, Enable SaaS Enable Value-Added Services Enable Unique Services Mandate Cloud Usage The Steps Aren’t Easy… Different Companies Different Speeds Different Needs
- 24. ©2008–17 New Relic, Inc. All rights reserved#FutureStack • Experiment • Cloud Policies • Enable Servers, Enable SaaS • Enable Value-Added Services • Enable Unique Services • Mandate Cloud Usage Cloud Adoption Strategies • Experiment/Peripherial Usage • Cloud Servers • Managed Components • Unique Components • Application Cloud Committed Enterprise IT Cloud Adoption Strategy Application Cloud Adoption Strategy
- 25. ©2008–17 New Relic, Inc. All rights reserved#FutureStack Application Adoption Corporate Adoption Cloud Adoption Mandate Committed Allow Value-Added Allow SaaS Allow Servers Cloud Policies Experiment Experiment Servers Managed Components Unique Components Committed Critical Applications New Applications Non-Critical/ Internal Applications Step #1 Step #2 Step #4 First Steps Application Re-Writes Step #3
- 26. ©2008–17 New Relic, Inc. All rights reserved#FutureStack Migrating to the Cloud… How can an enterprise be successful? ©2008–17 New Relic, Inc. All rights reserved#FutureStack
- 27. ©2008–17 New Relic, Inc. All rights reserved#FutureStack Adoption Success Strategies Understand your culture Create a Solid Plan Drive cultural change Monitor your adoption Understand your needs
- 28. ©2008–17 New Relic, Inc. All rights reserved#FutureStack Monitor Your Adoption Before Migration Baseline application (servers, databases, caches, applications, microservices) Determine your steady state
- 29. ©2008–17 New Relic, Inc. All rights reserved#FutureStack Monitor Your Adoption During Migration Incorporate cloud’s internal monitoring Continue application monitoring Understand and solve all deviations from steady state…
- 30. ©2008–17 New Relic, Inc. All rights reserved#FutureStack Continue Monitoring… Infrastructure is now out of your control Some cloud specific concerns (EC2 instance failures, instance degradation) Dynamic Technologies Impact Our Applications Understand application impact Ongoing application & infrastructure monitoring is essential Monitor Your Adoption
- 31. ©2008–17 New Relic, Inc. All rights reserved#FutureStack All Phases Before Your Migration Establish Your Steady State During Your Migration Understand and solve all deviations from steady state… After Your Migration Ongoing application & infrastructure monitoring is essential Monitor Your Adoption
- 32. ©2008–17 New Relic, Inc. All rights reserved#FutureStack Dynamic Cloud Dynamic Infrastructure Enables Highly Scaled Applications Enables High Availability ©2008–17 New Relic, Inc. All rights reserved#FutureStack
- 33. ©2008–17 New Relic, Inc. All rights reserved#FutureStack Lee Atchison ∙ Senior Director Strategic Architecture at New Relic. leeatchison@leeatchison Thank You.
- 34. ©2008–17 New Relic, Inc. All rights reserved#FutureStack This presentation and the information herein (including any information that may be incorporated by reference) is provided for informational purposes only and should not be construed as an offer, commitment, promise or obligation on behalf of New Relic, Inc. (“New Relic”) to sell securities or deliver any product, material, code, functionality, or other feature. Any information provided hereby is proprietary to New Relic and may not be replicated or disclosed without New Relic’s express written permission. Such information may contain forward-looking statements within the meaning of federal securities laws. Any statement that is not a historical fact or refers to expectations, projections, future plans, objectives, estimates, goals, or other characterizations of future events is a forward-looking statement. These forward-looking statements can often be identified as such because the context of the statement will include words such as “believes,” “anticipates,” “expects” or words of similar import. Actual results may differ materially from those expressed in these forward-looking statements, which speak only as of the date hereof, and are subject to change at any time without notice. Existing and prospective investors, customers and other third parties transacting business with New Relic are cautioned not to place undue reliance on this forward-looking information. The achievement or success of the matters covered by such forward-looking statements are based on New Relic’s current assumptions, expectations, and beliefs and are subject to substantial risks, uncertainties, assumptions, and changes in circumstances that may cause the actual results, performance, or achievements to differ materially from those expressed or implied in any forward-looking statement. Further information on factors that could affect such forward-looking statements is included in the filings New Relic makes with the SEC from time to time. Copies of these documents may be obtained by visiting New Relic’s Investor Relations website at ir.newrelic.com or the SEC’s website at www.sec.gov. New Relic assumes no obligation and does not intend to update these forward-looking statements, except as required by law. New Relic makes no warranties, expressed or implied, in this presentation or otherwise, with respect to the information provided. Safe Harbor
Hinweis der Redaktion
- Goals for deck Availability is more than you think it is…(not just up, but performant) Slow is worse than out... How do you even measure availability? Availability thru your customer’ Dynamic cloud helps make availability happen (n ways it make it easier) Unless you muck up these parts How do you get there? (what are the key takeaways) (anchor slide for each topic and end with it)
- What do I mean by using the cloud as a “dynamic tool for dynamic applications”? I mean: Use only the resources you need <click> * Allocate and deallocate resources on the fly <click> * Resource allocation becomes an integral part of your application architecture.
- In a dynamic application, resources are allocated, consumed, and deallocated on the fly. And the application is aware of and is controlling this management of resources. The application is essentially performing traditional OPs resource management tasks.
- New Relic did an analysis recently about how our customers are making use of Docker. The question we wanted to answer was, how long do docker containers live? This diagram shows the answer to that question. The horizontal axis is the number of hours a docker container has lived for, and the vertical axis is the number of containers in that time bucket. As you can see, there is a long tail, with some docker containers running for well over a year. However, there is a huge number of docker containers that run for less than one hour. In fact, if we zoom in on just that one hour time period…
- we can see that most docker containers we run actually only run for less than one minute! Over 11% of all docker containers we run will run for less than 60 seconds. This is some customer’s application or service, some business logic, that starts up, runs, and shuts down all within 60 seconds. This is very rapid. These are containers that are launched only for a specific business purpose and are terminated when that purpose is completed. This is what we mean by dynamic infrastructure.
- And there are lots of different cloud technologies that can be used in this dynamic manner…from queues to routing to auto scaled EC2 instances. Many resources in the cloud can be used in this dynamic fashion.
- So, in the old world, your operations team was comfortable. They knew the resources they controlled, they created them, they managed them. All was simple and manageable.
- But in this new world, resources are created and destroyed dynamically. The world of the operations team can no longer be as simple as tracking resources on a spreadsheet. The resources they are responsible for are dynamic and transient. Their world has gotten a lot more complicated.
- So, that’s all great data. I know I need to move to the cloud to keep my company moving forward. But what about the nuts and bolts. What should *I* do to be successful in moving to the cloud?
- Let’s take a look at how most enterprises figure out how to migrate to the cloud. There are six *typical* steps that most companies take to move to the cloud. They don’t all use all the steps. Some stop part way up the path. Some skip steps. But this is typical… Let’s look at each of these in turn.
- Let’s start with “Experiment”.
- This is the first, tentative step into the cloud. It involves using safe technologies. Technologies that we can use in simple and subtle ways in parts of our applications that may be less critical. There are no cloud policies created. We just build one off implementations to see how the cloud can fit into our needs. Most companies have at least started on this step.
- After you’ve done some basic “feet wetting” in the cloud, security typically becomes a concern.
- Critical evolution point in the company’s culture …all displines in the company are involved (Legal, Finance, Security) …companies that can’t get past this point, can’t be successful in the cloud
- Once policies are in place and the cloud can be trusted…you start using other features the cloud has to offer.
- Three choices: ...1) Put some workloads in the cloud, some in your own data center ...2) Resiliency - additional data center(s) ...3) Move applications to the cloud, out of existing data centers Independently: SaaS uage increases (internal apps first)
- Now the cloud is important to you, so you start to see what else the cloud can do for us.
- Three choices: ...1) Put some workloads in the cloud, some in your own data center ...2) Resiliency - additional data center(s) ...3) Move applications to the cloud, out of existing data centers Independently: SaaS uage increases (internal apps first)
- Now, we start looking at cloud native services…services only available in the cloud.
- Three choices: ...1) Put some workloads in the cloud, some in your own data center ...2) Resiliency - additional data center(s) ...3) Move applications to the cloud, out of existing data centers Independently: SaaS uage increases (internal apps first)
- So now we are committed to the cloud…now comes the last step. Mandated use.
- Three choices: ...1) Put some workloads in the cloud, some in your own data center ...2) Resiliency - additional data center(s) ...3) Move applications to the cloud, out of existing data centers Independently: SaaS uage increases (internal apps first)
- But ultimately, these are the steps involved. Different companies go thru these steps at different speeds. Different companies find the right “stopping point” that matches their needs
- While these are the steps our *company* may go thru. As we build new and migrate existing applications, our applications go thru a similar learning process… How can a given application take advantage of the cloud? This adoption may happen faster or slower for different types of applications.
- Let’s take a look at these as two different axis on a chart. Coporate adoption process on the left, Application adoption process on the bottom Another way to look at this: based on application types and requirements...
- So, that’s all great data. I know I need to move to the cloud to keep my company moving forward. But what about the nuts and bolts. What should *I* do to be successful in moving to the cloud?
- How can I make sure a cloud migration is successful? Understand where your culture is Risk tolerance, Cloud commitment, Expertise Understand your needs Redundancy? Cost? New Opportunity? Consciously plan your acceptance What level are you? What level do you need to be? Drive your culture to where you feel you need to be Monitor your adoption
- Before migration Baseline application Servers Databases Caches Applications Microservices Determine your steady state Important before you migrate!
- During migration Incorporate Cloud’s internal monitoring …provides cloud specific infrastructure monitoring …AWS CloudWatch Continue application monitoring *Here, looking for performance deviations from steady state Track down & explain all deviations before moving on Understand all deviations from norm Solve problematic deviations/problems
- Continue monitoring post migration Should understand: The infrastructure is now out of your control…you need to keep an eye on it Cloud infrastructure changes can impact your application…you need to keep an eye on it There are some cloud specific concerns: EC2 instance failures Greater part of your availability plans Often impacts other AWS systems as well Instance degradation (more common than you’d think) Ongoing application & infrastructure monitoring is essential
- Before, During, and After Your migration. Monitoring plays an important role in your entire migration process.
- So, that’s all great data. I know I need to move to the cloud to keep my company moving forward. But what about the nuts and bolts. What should *I* do to be successful in moving to the cloud?
- Let’s be careful out there…