Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (15)
Similar to Chris Wells Magento Imagine 2015 Breakout - Leveraging the Cloud for Ecommerce
Similar to Chris Wells Magento Imagine 2015 Breakout - Leveraging the Cloud for Ecommerce (20)
More from Nexcess.net LLC
More from Nexcess.net LLC (7)
Recently uploaded
Recently uploaded (20)
Chris Wells Magento Imagine 2015 Breakout - Leveraging the Cloud for Ecommerce
- 2. Chris Wells CEO - Nexcess
- 3. Overview
- 4. A Typical Cloud Session Outline • The problem: Scaling • The process: • The solution: Cloud
- 5. The “Why” • Operational efficiency • Economic efficiency • In other words: Sales without FAILs
- 6. The Problem • Scaling is hard • Application architecture can make it easier! • Or more difficult
- 7. Types of Scaling 1) Vertically (scaling up)
- 8. Types of Scaling 1) Horizontally (scaling out)
- 9. Let’s scale out some bare-metal!
- 11. Metal Problems
- 13. The Cloud Promise • Infinite scale, instant and seamless • Infinite redundancy • Set-it-and-forget-it
- 15. “People want to treat the Cloud like they would a toilet. Input is simply provided and ideally everything else ‘just works’.” - Chris Wells Toilet user
- 16. The Cloud Reality • Cloud was never meant to scale – Vertically – Reliably – Infinitely – Easily
- 17. The Other Cloud Realities • Cloud implies an environment is: – Redundant • But it shouldn’t – Scalable • But it shouldn’t – Performant • But it shouldn’t – Cost efficient • But it shouldn’t
- 18. Cloud marketing sucks
- 19. I’m Sorry Cloud, It’s Not Your Fault • Cloud can be great for quickly scaling* • Cloud can help with redundancy* • Cloud can help balance OPEX/CAPEX*
- 20. Cloud itself can be pretty awesome
- 21. The “Cloud” Version 1
- 22. Scaling the V1 Cloud
- 23. V1 Cloud Issues • Inefficient use of virtualization – Is it even needed? • Inherits many of metal’s problems – Shared storage – Configuration management – Networking
- 24. How do we actually leverage the cloud?
- 25. Move beyond simply cloud clustering
- 26. Start thinking in terms of (micro) services
- 27. A Service View of Magento
- 28. The Cloud Version 2 • Built on (micro) services • Ensure service elasticity • Use services to augment metal
- 29. Leveraging The V1/V2 Clouds • Don’t believe the hype • Focus on architecture • Elastisize all the things (services)!
- 30. So, is bare metal dead? (hint: no)
- 31. The best technology is the one that works (for you).
- 32. Thank you! More info @ booth 507
- 33. Thank you! • Please also check out: – Human Element / Nexcess 2-factor authentication plug-in • FOSS – Nexcess Percona (PXC) Whitepaper – Nexcess Magento 2 Performance Overview Whitepaper – https://www.nexcess.net/imagine2015
Editor's Notes
- Cloud computing promises turnkey elasticity for e-commerce stores, but the reality of leveraging the cloud for scaling is not so simple. This session today will go over what you need to consider in leveraging cloud.
- This is how I feel like most talks on cloud go
- You want predicable resource availability. That is, you want resources when you need them and not necessarily when you don’t given the capex requirements of having resources sitting idle. The quintessentially example here is the shark-tank or good-morning-america factor where sometimes (which little notice) your site is spotlighted and you need resources but this isn’t an every day event. So a 2nd “why” on in terms of scaling is to invest is resources when you need them and only when you need them. This brings the economic efficiency of not having idle resources burning through capital. Essentially, you want to spend money when needed and only when needed – in other words what I call “making sales without making fails”
- Let’s circle back for a second because I’m sure this all sounds pretty straightforward to this point. You scale when you need and only when you need, can’t really argue there, so what’s the issue? Essentially while the idea is easy in practice the process isn’t. That is, scaling is hard. Now, that isn’t to say it’s impossible and honestly some applications actually lend themselves very well to out-of-the-box scaling but unfortunately others don’t and that’s where we’re going to focus some effort here today.
- Before we get too far into the nuts and bolts of scaling I’d like to talk for a second about some of the simple primitives of scaling so we’re on the same page. For the sake of example, imagine you’re at the grocery store and you, along with other shoppers are competing for the single open check-out counter. You’re essentially stuck in a single line and there are no other options. To make things worse the cashier is new and fumbling with each item as they swipe it over the scanner. Now, imagine we wanted to be able to simply get more items through the checkout to allow the process to speed along. An obvious “upgrade” here would be to have a more seasoned cashier step in which would instantly allow for faster throughput and it would INCREASE performance. That’s vertical scaling, or scaling up. We have been scaling in the bare metal world for ages and we all do it with our home computers as well. Need more disk? Add disk. Need more ram? Add ram. Etc. Vertical scaling can work great, to a point and that brings me to the next type of scaling.
- Imagine instead of scaling up the single checkout with bigger carts, seasoned cashiers, better scanners we simply opened more checkout lanes. If there are available and idle this can be a simpler and cheaper operation. If they’re not there already.. Well, we’ll get to that.
- So let’s look at a concrete example of how bare metal is scaled out (that is, horizontally scaled).
- On your left is something that should look similar to most. It’s a basic 2 web app server cluster with a load balancer, DB server and file server. Yes, yours may be different in practice but for the sake of example this works. Now, when we scale this out we’ll be adding more nodes to the system. In this example we’ve simply added more web app servers and DB servers but we could have added more file servers, load balaners etc as needed. This is a tried and true method of scaling. It works very well and many of our clients use this to this day. Now, there are problems here, but it’s not with the ability of this solution itself to do the job, it’s with the time it can take to implement the solution on your right once it’s requested. This brings me to what I call ‘metal problems”
- No, not those kind of metal problems What I’m talking about is the metal problems that involve actual physical labor. You see, to add metal resources to a system is labor and time intensive. You have to: Get the server from inventory Test the server Rack the server in the data center in the rack it will ultimately live (which may be a hike from testing and/or inventory) Cable the server (which can be time consuming believe it or not) Install the OS, secure the server, harden it, install core services, configure those services And NOW, you’re ready to actually introduce this server into the mix All in all it’s not designed to be quick, but that’s OK, because we have a solution.
- Queue 2001 theme You folks better be ready for the revelation of the century Here it comes…. Ok, it’s the puffy white thing that we all call cloud that we’ve seen for the last decade It’s supposed to fix all of our problems, just look at how powerful it looks At this point most presenters would adjourn as the job has been done. Cloud is here to save the day, enough said. I’m not as optimistic that this puffy thing can help me by itself, on it’s own so let’s dive a little deeper and see what it can offer.
- This slide makes me sad. This is what we were told. Every bullet on here I can relate to and I hope you can to. The cloud just works. It’s infinite, it’s instant, it’s there when you need it. It can take whatever you give it and the cloud will never run out. It’s like the toilet paper at your hotel room. And like the toilet paper in your hotel room it has infinite redundancy as well. It never breaks. There’s always more cloud. You simply set it and forget it. Heck, you can even buy the cloud for your house
- You guys are going to hate me for the next slide but I’m going to push this button anyway.
- - So what I’m getting as is that there’s a really here with the cloud that we’re just not addressing. And that is this: The cloud was never meant to scale. Ok, before you all rush the stage let me quality this statement. It wasn’t meant to scale vertically. That is a given cloud instance can only vertically sale so big and the funny thing is that most folks don’t know that the biggest that a cloud instance can scale is the size of the server on which it lives. If you want to scale the cloud beyond that you have to scale the server (which is ironic). Next, the cloud was never meant to scale reliably. I again can see the puzzled look on your faces. This brings me back to architecture for a second. The cloud simply provides primitives and with them you *can* scale reliably but it’s not an out-of-the-box operation. Next the cloud was never meant to scale infinitely (heresy I know). Everything has limits and the cloud has many of the same limits as bare metal. They are simply obfuscated a bit, which is actually OK. And finally, the cloud wasn’t meant to scale easily and this is the crux of the matter. It requires architecture, engineering and effort to make all of these things happen.
- I almost took this slide out, I really did, but I think it’s important so we’ll breeze through it and get to my bigger point. When you hear “cloud” so many things come to mind (and hopefully toilets after this talk) but what *shouldn’t* come to mind, or what shouldn’t be implied, are the following. Redundancy, the cloud shouldn’t imply it, but it does. Scalability, the cloud shouldn’t imply it, but it does A performant environment, you know the drill And finally cost efficiency. These are al implied by the mere word “cloud” and they all shouldn’t be. Over the last 5 slides I had 1 goal and it probably isn’t what you thought it was going to be. That goal is to say:
- If there’s anything you learn today about levering the cloud it’s that you have to read through the marketing Ok, now that we’ve got all of that out of the way let’s talk about how cloud is used today and some of the nicities of cloud.
- Ok, I’m going to make my amends with cloud. Cloud is the right solution for a number of things and it has tangible benefits if you don’t buy the marketing at face value. First, the bare metal issue with the technician and all of the server operations. Those problems are away and you can quickly scale vertically (to a point) and horizontally. With the right implementation you can add in redundancy and with the right implementation you can also balance opex and capex You’ll notice my asterisks by each one of these and my overall brevity on this topic. The asterisk is meant to mean “some assembly may be required” so to speak.
- Ok, so the marketing sucks, I guess I can forgive that because cloud itself allows for some pretty cool things. Let’s look at how it’s used today.
- In what I call the “version 1” cloud or the 1st iteration of how folks have used the cloud we’ve taken our bare metal metaphors shown on the left here and translated them into the cloud. Where we once had servers we now have virtual machines.
- - If we want to scale this v1 cloud it essentially is the same as horizontally scaling our bare metal cluster albeit the spin up of the VMs is quicker there may still be a lot of configuration to deal with and it’s not the turn-key operation many would assume. This is why we see so many PAAS providers built on top of AWS. The only thing stopping merchants going direct to AWS is complexity and it’s funny (at least to me) to say that AWS is so complex that businesses have to be built on top of it to make it useful.
- Before we go any further I wanted to stop and say a few things about this wholesale conversion to the cloud that we’ve seen over the last X years. It seems like many have adopted cloud just for the marketing hype and haven’t sat down and thought about what parts of their business need to be virtualized (and what parts don’t). WE have to ask if virtualization is even needed. While many use cases can be solved with cloud there are many that it can simply add complexity to. Also, if we’re just duplicating the “cluster” metaphor in the cloud we also get with it many of the problems that the metal cluster has simply by inheriting the metaphor. Shared storage can still be a problem as can configuration management, network and other issues. So we have to ask ourselves the question then:
- Ditch the cluster metaphor or at least redesign it in a way that uses cloud for what cloud is good for
- Loose coupling Other software metaphors Failing fast Throwaway
- Don’t assume cloud means what the marketing says Don’t assume cloud will simply solve all of your scaling problems because the word cloud itself is used Understand that cloud based technologies are constantly changing and things are moving in a direction of resources rather than server roles Make sure ALL of the underlying resources are as elastic as they can be
- Having additional metal assets can scale quicker than cloud Hybrid for DBs Burst into cloud Better for sustained traffic YOU CAN LEVERAGE THE CLOUD BY: USING THE RIGHT SOLUTION FOR THE JOB (ANECDOTE ABOUT VERTICAL SCALING DB BEYOND CLOUD BUT CAN BURST TO CLOUD WITH CACHING) Leverage cloud by using it for what it’s good for.
- Having additional metal assets can scale quicker than cloud Hybrid for DBs Burst into cloud Better for sustained traffic YOU CAN LEVERAGE THE CLOUD BY: USING THE RIGHT SOLUTION FOR THE JOB (ANECDOTE ABOUT VERTICAL SCALING DB BEYOND CLOUD BUT CAN BURST TO CLOUD WITH CACHING) Leverage cloud by using it for what it’s good for.