Software that eats the world! - PerformDay Brussels
•Télécharger en tant que PPTX, PDF•
1 j'aime•213 vues
Software is changing the world and how useres
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (19)
Similaire à Software that eats the world! - PerformDay Brussels
Similaire à Software that eats the world! - PerformDay Brussels (20)
Plus de Klaus Enzenhofer
Plus de Klaus Enzenhofer (12)
Dernier
Dernier (20)
Software that eats the world! - PerformDay Brussels
- 1. Software that eats the world! Klaus Enzenhofer @kenzenhofer
- 2. 2011 “In Short, Software is eating the world!” https://en.wikipedia.org/wiki/Marc_Andreessen
- 3. Largest companies in the world by Market Cap Rank 2011 2012 2016 (Q3) #1 Exxon Mobil Apple Apple #2 Petro China Exxon Mobil Alphabet (Google) #3 Apple Inc. Petro China Microsoft #4 ICBC Microsoft Amazon #5 Pertobras IBM Facebook
- 4. 3 Things to cover Today!
- 8. 3 Things to cover Today!
- 9. Cloud
- 11. We need to go cloud!
- 12. Anyone Failed? Anyone had an issue?
- 14. Do NOT trust the cloud! Lesson learned #1:
- 15. Constantly test the APIs and their responses
- 16. DB DB CLOUD Based Applications Web Web AppServer A AppServer B DB AppServer A is going down! Thanks for telling me a week too late!*****
- 17. vCPU != physical CPU Lesson learned #2:
- 18. actually 1 vCPU = ½ physical Core vCPU != physical CPU test your sizing in the cloud!
- 19. Hybrid deployments are complex Lesson learned #3:
- 20. Data Center Applications Web Legacy CRM AppServer AppServer AppServer AppServer AppServer AppServer DB MF 3rd Party Web Web AppServer AppServer AppServer DB DB DB CLOUD Based Applications Web Web AppServer AppServer DB
- 21. Data Center Applications Web AppServer DB CLOUD Server Server Server Server Data Center Applications Web AppServer DB …… I cannot handle domain names! Give me an IP
- 22. Work with your provider! Lesson learned #4:
- 23. Microservices +
- 26. 3 Things to cover Today!
- 28. Who is doing SLA Monitoring?
- 29. Any one a salary depending on it?
- 31. Google - Mobile Friendliness Campaign?!
- 32. Contract SLA: Average Response Time < 3 sec User on Desktop + Mobile
- 33. Good idea?!
- 34. 4.5 sec 15 sec UserDeveloper Operator
- 36. Let‘s take a look at the timings! Navigation Start: 0 ms Domain Lookup End: 269 ms Connect End: 330 ms Response Start: 517 ms Response End: 518 ms Dom Loading: 519 ms Dom Interactive: 519 ms DomContentLoaded Event End: 520 ms Dom Complete: 520 ms
- 37. 0.5 sec 0.5 sec Developer
- 38. User Operator
- 39. User
- 41. DNS Lookup Initial connection TTFB (HTML) Download Life of an URL request
- 42. Starting here, we are able to control …
- 44. <script src=“angular.js”> blocking! <script src=“main.js”> blocking!
- 45. <script src=“angular.js”> blocking! <script src=“main.js”> blocking! start render
- 46. <script src=“angular.js”> blocking! <script src=“main.js”> blocking! start renderresponse time
- 48. Browser App ServingassetsAPIServer GET /app JavaScript payload GET /api/users JSON payload GET /api/posts GET /api/pages JSON payload JSON payload Send index.html Request JS application
- 49. Browser App UniversalrenderingAPIServer GET /app JavaScript payload GET /api/users JSON payload GET /api/posts GET /api/pages JSON payload JSON payload Initial render HTML + CSS Request JS application
- 53. 4.5 sec 6 sec UserDeveloper Operator
- 54. Operator
- 55. The CDN bill exploded!
- 56. 285 Resources for an initial Page Load 151 CSS and 121 JavaScript files
- 57. ~200 Resources had larger Header than Body
- 58. User
- 63. Back Home
- 64. Back Home
- 65. HTTP Archive – Transfer Size Trend http://httparchive.org/trends.php Average Size ~2 500 KB By 1.6 € per 100 KB 40 € to get started!!!!
- 66. 2. Page weight
- 67. There’s lots of ways to reduce the payload
- 69. Reduce styles
- 70. Tree-Shaking to reduce JS
- 71. 2 sec 2.5 sec UserDeveloper Operator
- 72. Questions Slides: slideshare.net/kenzenhofer Get Tools: bit.ly/dtpersonal YouTube Tutorials: bit.ly/dttutorials Contact Me: klaus.enzenhofer@dynatrace.com Follow Me: @kenzenhofer Read More: blog.dynatrace.com
- 73. Klaus Enzenhofer Director Technology Strategy @kenzenhofer http://blog.dynatrace.com
Notes de l'éditeur
- We can fulfill the prophecy of Marc and can run these apps in a successful way
- https://en.wikipedia.org/wiki/List_of_public_corporations_by_market_capitalization#2016
- http://2.bp.blogspot.com/-Q1_BQdsCi1w/VhvoDLHiVHI/AAAAAAABcPI/1oFi1gMuDpg/s1600/Dramatic%2BLenticular%2BCloud%2BFormation%2Bover%2BHarold%2527s%2BCross%252C%2BDublin.jpg
- http://www.dailymail.co.uk/sciencetech/article-3294994/How-check-phone-Average-user-picks-device-85-times-DAY-twice-realise.html
- API definition (including error code) changes all the time => run tests against the API regularly to detect any changes
- You might get a notification that an instance is going to be retired next week… when in fact the instance has already been retired => plan for automatic fail-over & restoration
- http://www.dailymail.co.uk/sciencetech/article-3294994/How-check-phone-Average-user-picks-device-85-times-DAY-twice-realise.html
- Hybrid deployment (one part in onPrem & the other in the cloud) increases complexity and potential for issues Example: We provide our customers a domain name (name.dynatracesaas.com) & elastic IP (static IP provided by AWS). Customers need to enable their firewall to connect to our server – some firewall can only enable IP address – not domain name. We had an instance failover (kernel panic), as a result, the instance “lost” the elastic IP and another IP was automatically assigned. We had to work with AWS support – it took 4 days to recover the IP address that was originally assigned.
- Hybrid deployment (one part in onPrem & the other in the cloud) increases complexity and potential for issues Example: We provide our customers a domain name (name.dynatracesaas.com) & elastic IP (static IP provided by AWS). Customers need to enable their firewall to connect to our server – some firewall can only enable IP address – not domain name. We had an instance failover (kernel panic), as a result, the instance “lost” the elastic IP and another IP was automatically assigned. We had to work with AWS support – it took 4 days to recover the IP address that was originally assigned.
- Work with the cloud provider to 1) get quicker access to support 2) make sure your personal is well trained and understand the cloud technology
- So we need to have a strategy how to monitor small, medium or extremly large environment
- B2W example. 9 applications are HEALTHY!!!! only services have issues, but thats fine. 3300 servics running on 10k JVMs on just 142 hosts thats no longer for human doing visual monitoring; ist ideal for intelligent monitoring systems to deal with
- https://www.google.com/webmasters/tools/mobile-friendly/
- https://www.google.com/webmasters/tools/mobile-friendly/
- https://www.google.com/webmasters/tools/mobile-friendly/
- https://www.google.com/webmasters/tools/mobile-friendly/
- https://www.google.com/webmasters/tools/mobile-friendly/
- Gleiche Bedingungen. Only difference: Device and Browser! HTTP2 vs HTTP1 More Calculation Power …
- UX vs DX
- Alright Klaus, let’s take a look at the user first… why is the user still wearing his sad face even though our SLA seems to be fulfilled.
- Well it’s most likely due to the fact the user is seeing something like this. Can you figure out what this application should do? No? Me neither… That’s because it’s missing one vital part to be of use: The content. So why is this happening?
- Let’s see how an URL request is constructed. You all have seen this before. We do a DNS lookup to see where we get our resources from, connect to the server, let the server handle the response and download the resource. Usually, the first request you’re doing is to an HTML page that contains all the markup and references to the content we want to display.
- So once this first HTML file is downloaded, we have the ability to control what’s happening in the front-end.
- With a single page application framework we usually do something like this: Downloading the framework’s JavaScript file! Resulting in a blocking request until we get some content on screen.
- We’re also downloading our own application of course, resulting in much likely a more longer request than before. Still blocking until we get some contents on screen. On mobile, this takes even longer because of network latency. Every request adds several round trips until you get to an actual response. And I’m just counting the response time of the resources here, not the time it needs to actually interpret and execute the JavaScript code that we just downloaded.
- Once this is done, we finally see the content rendered. This can take up to several seconds. If you follow the guidelines of your framework, you load the JavaScript files and the end of your application, and most likely asynchronous and deferred. Which means that those requests don’t add up to the response time.
- The actual response time of your application triggers when the original HTML file is downloaded! Resulting in this huge gap between response time and perceived render time.
- Let’s take a look into that in detail.
- Usually, we request the app, it delivers a static HTML file, we request the JavaScript application, and after that’s rendered, we make calls to an API server. Classic SPA.
- With server side rendering we want to make the first response count. Deliver everything that is needed to actually see content and allow the user to interact with the application. Then the JavaScript application loads and takes over. Perfect idea of progressive enhancement with single page applications!
- There are lots of solutions already out there. If you use Ember, having server side rendering comes for free. You install Fastboot, and fastboot does everything for you.
- It’s a little more complex in the React ecosystem. As usual, you have lots of choices which are all varying in the details. Also, there’s no switch-on solution, you have to do a lot by yourself. On the plus-side: There are solutions that work with other server environments than Node.js.
- Angular 2 also has a server side rendering solution called “Universal Angular 2”, which is pretty much in the vein of Ember’s fastboot.
- So with that, we make our user somewhat happier... But we still have a sad operator
- UX vs DX
- 1. Bandwidth topic and dataplan 2. “Klausi did a Journey”. Australia story 4$ per MB 3. What does my site cost www.whatdoesmysitecost.com 4. Roaming??? 5. Local: Income vs data plan 6. Header vs Payload HTTP1 Problem Solutions: Reduce to essentials Tooling Uncss, Treeshaking, Do I need this fancy pop-up?, Responsive Images
- You know that already, there’s lots of ways to reduce the payload we’re sending to the client. Running your images through ImageOptim, minifying and gzipping your CSS and JavaScript, all things that are by the book. So let’s what else can we do and what’s directly geared towards mobile web.
- The idea of responsive images is that you have a ton of different screen sizes, why download the same image to all those varying screens. Why not tailor the payload of an image as well as the content of an image to the screen at hat. The Responsive Images Community Group did an outstanding work in specify a standard. There’s a lot to this standard, including new elements and new browser algorithms, but I want to show you a quick example that’s sort of a quick win with Responsive images.
- It’s called UnCSS and is super helpful if you use frameworks like bootstrap. Bootstrap comes with a gazillion of components, but most sites only use roughly 20% of it. This tool checks which parts of this framework are used on that page, the rest is removed.
- And Google’s Closure compiler… this godfather of JavaScript minifying tools is also the one that’s being used in AngularJS 2.
- Gleiche Bedingungen. Only difference: Device and Browser! HTTP2 vs HTTP1 More Calculation Power …