The Evolution of Hosting and What's Next with Cloud

Editor's Notes

• #5: One thing I like about doing these presentations is I get to do some pretty fun image searches and call it “work”. Here’s some of my favorites when searching evolution.
• #6: I tried to find a few of these you could identify with, so you would identify with me maybe, and we’d be friends for at least the next hour or so. So here goes for my Star Wars fans out there.
• #7: And this one for those of us battling against our Dad Bods.
• #8: ...and for the zombie, or walking dead, fans.
• #9: Trying to hit all potential audience groups we have the evolution of England’s home kit from 1965 to 2014.
• #10: I’m a big shoe guy, a sneaker head if you will, I don’t like feet, they’re gross, but I love shoes.
• #11: I know we all have smartphones now, but who had one of the Zack Morris brick phones?
• #12: Getting more focused on the topic today we can take a quick look at the evolution of technology.
• #13: There’s been some interesting innovation with the light bulb recently. We have LED’s of course, but this is an LED bulb with a bluetooth speaker built in. It seems great, but it’s not great. You get into a battle between getting your light to turn on or playing music, it’s an interesting combination, but not a great one in my opinion, at least they’re trying to disrupt a commodity item though.
• #14: Being based in outside of Detorit, MI we’re a bit partial the automobile industry. This one was interesting because BMW is sort of known for innovation. Be it the way the car handles or the interior, or the nav/computer system, they always seem to be iterating and overall they make great cars. Then there’s the LADA classic, which went largely unchanged for decades. It was reliable, had a low cost of ownership, and you could drive them forever. Not much innovation, it just worked. This is something to keep in mind as we get into the meat of the session.
• #15: My name is Josh Ward and I work for Nexcess. We’ve been around since 2001, own and operate data centers, started working with Magento back in 2008, provide managed web hosting to over 40k Magento websites, and the evolution of our industry is something we’ve been thinking about...a lot...like all the time.
• #16: It does, I was at a networking event on Friday and met someone from a large web design firm with offices in the US and Italy. They design and host large, brand nmae sites you’ve probably been to or bought from before. Like a good sales person I asked who they used for hosting? He said in their offices and that it was funny I mentioned that. Apparently it’s getting hot in their offices in Italy because it’s summer and they have no ac. So people are bringing AC units into the office and the increased load is bringing down the servers. If you’re a merchant this should scare you, if you’re a developer you shouldn’t be doing this, if you are doing this see me after the presentation, we’ll help you, the first step to getting better is admiting you have a problem.
• #17: Back in the day, like 1995ish, if you wanted to host a website you either needed your own server and internet connection knowledge of all things computer science or you needed an account at places like Geocities, Angelfire, and Tripod.
• #18: Largely unchanged since the early 2000’s. You can develop locally, but you’re local environment never quite matches up to the production environment, makes testing difficult, you can duplicate the site as an addon domain or secondary domain but then you’ve got dev and production in the same environment which isn’t great, also there’s typically a lack of dev ops tools built into the control panel which means you’re relying on 3rd party or bespoke tools.
• #19: Very similar to shared hosting, it’s easy because it’s managed, essentially the same development issues. At this price point you can probably afford a smaller dev server, if you’re doing you’re own management of the system it’s easier to duplicate the environment locally for dev, but then you have to go through the trouble of updating two or more systems every time you make a change, also, you need sys admin help at some point to support the server and keep things up to date, more PCI considerations etc. Without a good managed service provider this becomes mostly hard instead of mostly easy. Also, these considerations are largely true for any kind of single instance virtual or cloud server.
• #20: Again, similar considerations as a dedicated in terms of support, management, and development, but it still works. There’s a pretty well advertised case study about a 10 day Mangento 2 build for a popular time piece website. We provided the hosting for that build. It can be quick and it can scale. It works.
• #21: What we, the hosting industry, has largely done is just virtualize our “traditional” cluster environments. Each server is still playing multiple roles, all servers are still exposed to the public network, dev ops tools can be rigid and may not fit your approach, it’s not an application focused architecture, meaning you may not need apache to scale for your application, but if you need more PHP you’re getting more apache too.
• #22: These are the challenges in hosting we need to overcome. These are problems and short falls we’ve traditionally had too. (Need to be a bit self deprecating here before showing off the awesomesauce).
• #23: A quick word of caution. What you’re about to see is fucking awesome! Here’s how we’re solving problems.
• #24: You start with a project. This is essentially your workspace for the application.
• #25: Name your project, reference a domain, choose your application and link your git repo and branch. We’re letting the developer drive everything through their git repos. This allows you to use use your various levels of versioning and feature control.
• #26: Next you’re going to create your cloud application environment. This is where the fun starts. As you’re creating the environment you’re not yet pushing your code.
• #27: You’ll set the type of environment for tagging purposes, select location, size, and then SSH keys. The keys are more secure, prevent the emailing of passwords, and are probably something you’re already using.
• #28: Now this environment is something special. First, we automatically start with 9 vm’s. Each is tuned for the specific application you’re running. Only one has a public IP address. The remainder are behind a client private network or CPN. We terminate SSL at the web application load balancer so all the traffic inside the CPN is un-encrypted which makes troubleshooting easier. Every VM handles a single service, NGINX, PHP, MySQL, etc. All one vm to one service. Each also has a LB in front of it. This allows for easy horizontal scaling and high availability. It becomes more application specific because if you need more PHP, you don’t also get more NGINX. Only scale the service you need. Each VM also has it’s own firewall, malware and antivirus, PCI scans, and backups. Each with status indicated by the flags above the VM. On the side there you’ll see some metrics in terms of PHP processes, FPC, and User Sessions. These are data points that can trigger scaling events. All based on the specific site, application and architecture. This is truly a step forward in cloud architecture.
• #29: Now, once you have your environment the fun isn’t over. What about those development issues? The first thing to notice is you can pull down an exact copy of your environment via a Vagrantfile. This allows you to easily setup an exact copy of our environment locally. You’ll be able to see all our optimizations and then push your code to the local environment via an Ansible file. Templates provided of course. Or you can easily create a new cloud environment for each step in the development process on our infrastructure. You’d just select the environment and choose deploy.
• #30: Vagrant file, ansible stuffs, etc.
• #31: At this point you’ll need that Ansible file again in your git repo, then just indicate which repo and branch you want to deploy and push go.
• #32: Overtime you’re going to have multiple deployments. We’ll keep a history of these so you can launch a new environment and deploy something from earlier. You can also pull down a vagrantfile with the exact environment settings for that specific deployment. This way you can debug in the same environment where the issue arouse regardless of the environment changes since then.
• #33: These are our lions and tigers and bears...oh my. These are problems and short falls we’ve traditionally had too. (Need to be a bit self deprecating here before showing off the awesomesauce).