 Hello everyone. My name is Edward. I'm a deployment engineer at Engine Yard. For those of you that don't know, it's I'm also a Panda, which is our team mascot. It stands for polite agent of non-destructive assimilation. It's my job to answer technical questions from clients. Make sure they're successfully on board it onto our platform. And here we have Will Longo. He's an application support engineer, and he doesn't have a cool Panda nickname like myself. But so a lot of you guys know from last year's RailsConf that, or my team knows, that I completely messed up because it was my first time doing a conference, and I decided to do a live demo that required a strong internet connection at a conference. So yeah, needless to say it was pretty disastrous. So this is like my redemption conference. So let's go into it. I'm gonna talk a little bit about Engine Yard's classic product, which is our current product, and then our next-generation product, which is what we're looking to build. It's currently live, and it has some bits and pieces that are still being patched up, and we're hoping to do it in official release by the end of the year with all the features built into it. And now I'm gonna pass it off to Will to talk about support. Does that sound good? Sure. So here, if the last time you used Engine Yard was a long time ago, we've had a lot of changes. So right now, Engine Yard supports, of course, Ruby on Rails, PHP, Node.js, and Java, and for those of you that are interested in the Microsoft world, in addition to being on AWS infrastructure, we have Microsoft Azure as well as Verizon Terramarq. So here's the official, I don't know if you guys have seen this before, but this is the first page that you'll see when you sign up for Engine Yard. It's a pretty simple three-step deployment process. So this is step one. Tell us a little bit about your application, give us your Git repo, and boom, you can click create application. Step two is your environment configuration page. So you can create production, staging environments, and these are some of the configs that you can do to create your environment. So some of the notable features here is that you can select different regions on provision servers that are closest to your users, as well as that makes the most business sense. So you can see here we have Eastern, Western, Europe, Singapore, and Japan. You can also set up SSH keys and Engine Yard takes incremental backups of your application and database. So you can see here we also take full dump style database backups, and you can select a number of copies you want to keep, and how often you want these processes to run. So once you're done with that, that's step two. The final step is just to tell us how many servers you guys want. And we have a single instance, as well as a staging configuration and a production configuration. Most of the users just click on custom configuration. That way you can mix and match the number of servers that you guys want, select the types of servers you want and the sizes. And lastly, it's just choosing an Amazon public host name or adding an elastic IP. So the deployment process is pretty simple. Once you click boot, this is a fully booted environment. And I'm just going to talk a little bit about some of the things that you can do on this dashboard. You can click on visit your application. You can obviously, you can add servers on the fly. For those of you that are doing staging and development environments, you can click on the stop button and it will automatically take a snapshot, spin down your servers. And this is a good way for you to save costs within your environment. You can also deploy directly from your dashboard. And we also have a command line tool for those of you, obviously, that are very comfortable living in the command line. Moving down a little bit, you have your application servers as well as your database servers. So you have a pretty good view of everything that's happening within your environment. You can SSH directly, you have full root access into every single one of your servers. You can terminate your servers directly on this dashboard. And lastly, you can clone your environment. So should you have a staging environment that you've taken the time to put together and you're ready to move into production, rather than reconfiguring everything, all you have to do is click on the clone environment and it will boot up a completely new environment, similar with the exact configurations that you have done already. So moving on, that's the current product that we have. So right now I'm going to show you the next generation product, which is available right now. But like I said, it's going to be about the end of the year before we have everything up and running that's as seamless as the current product. If you're looking to deploy today, the most production environments should go on our current platform. So if you take a look here, it's still the same simple three-step deployment process. We couldn't get away from three unfortunately. But the first step is to create a project. Now the concept of a project is that within an organization you can have multiple projects that you work on, grant access to different developers that are working on different things, and be able to separate your applications within your environment. So you can choose a project, choose an environment, and click on create project. So before I show you step two, I want to talk a little bit about how the major platform changes the engineer has done on the new product. Currently, everything is a single stack. All your components are bunched into one. So whenever you will have stack upgrade stack releases, it has to be applied to the entire infrastructure. All the components are limited to being in one single region. So from a fall tolerance standpoint, if something goes down, the whole thing goes down. We've moved to this what's called a cluster model. So as you can see, we've really broken everything down into different tiers. And the benefits of this is not only do you have faster boot time, each of these clusters, for example, you have a low balancer cluster, an application cluster, and your database cluster. Each of these clusters can be provisioned into a different region. So it's really healthy in terms of high availability and being able to prevent it quickly. So just to show you a little bit about what that looks like, let's go into step two. This is what's called blueprints. So within a blueprint, you'll see that there's different, a blueprint is pretty much a template, pre-configured templates of different clusters. So you can see one cluster, one blueprint has app load balancer and database. And you'll see that one of them has a, in addition to those three, they have MAMCASHD clusters, Redis clusters. Now the future of this is to be able to create production-ready clusters, staging clusters, and also we can take popular applications that are at full scale on Engine Yard and create a template that for customers that are looking to scale to that size, this is something rather than having to figure out what that looks like, you can use these blueprints. And also the goal is for you to be able to save your own blueprints and share it with different people within your organization. So this is going to be very, very useful when it comes to just getting up and running quickly and not having to remember all the settings that you've configured. Because DevOps is, I mean it's already complicated enough, the hardest part is trying to remember what you did successfully and being able to take things that other people have done successfully and be able to use it. So this is a really, really great tool. So step two, and the final step is, for those of you that recognize, this is actually step one on the other thing, so we're trying to confuse you a little. Basically just select the language, give us the git repo again and select the location, and once you boot, this is the official dashboard, the new dashboard that's updated. Everything was rewritten in AngularJS, so the load time's much faster, it's easier for us to test, and from later on it's easier for us to evolve it as we continue to get feedback from our users. So you can see here that on the right hand side, you have easy clusters access. You can access every single one of your clusters by clicking on any of them on the right hand side. Each cluster you see here have application, database has its own set of servers, so you can see the health status of every single one of your servers within your cluster tier. And if you want more information, you can click on any of the servers themselves and be able to see what's going on, be able to add more servers, SSH directly into it of course, and be able to remove servers or add servers on the fly. So the last thing I kind of want to show you guys is something that we're going to launch as part of our end of the year, just to get things up and running. It's nothing super revolutionary, but I really think that it's something that's going to be very useful in helping you manage your servers. So here is a scheduled scaling policy that we're adding. So a lot of times we have customers asking us for the ability to be able to spin up and spin down servers without having to sit there and manage your environments. If you have upcoming events that you want to plan for, rather than you thinking about it, you can set what's called a scheduling policy. So you can click on add server, click on add a scaling policy, and here's what you see. And I apologize for the continuous loop. Like I said, the live demo was so traumatizing, I decided to use GIFs, so that's what you're seeing right now. So let me wait till it goes through. But basically when you're adding a scheduling policy, you can select the exact date, exact time, the exact number of servers that you want, and be able to have those servers spin up on those days. And then obviously you can have a reversal policy for the days that you want to spin down those servers. And another really cool thing is that you can set an exact number of servers you want. So if you have 20 servers and you know on a day you only need five, you can set it to be exact number of servers rather than scaling up and down. So this is going to be able to save you guys a lot of money, and the best part is just not having to manage your servers. I think the hassle is just being able to predict your traffic, and hopefully the end goal is to have auto scale, which is going to be sometime next year. So the last thing I'm going to pass it off to Will to talk a little bit about what Engine Yard is, the core of Engine Yard is our support team. And I think the biggest thing is that we've really built a name for ourselves in the Ruby on Rails community as being the go-to company when it comes to handling all your DevOps and supporting you throughout your entire process of your deployment. So I'm going to pass it off to Will to kind of talk a little bit about support. All right, I don't have any slides or anything, I just have some notes. So I might end up trying to figure out a cooler way to do this. But I'll leave the clock up. Oh, it stopped. That's unfortunate. Unlike the clock up here, we are a 24-7 organization, so our hand never stops sweeping around. One of the things that makes us a little bit unique is that we actually have completely distributed support. All of our support engineers are remote. And in fact, we're in multiple countries. All of us are working in our sort of nine to five-ish time zones. So when you call somebody in the middle of the night because something has gone wrong, then you're not getting somebody who's going through on Red Bull or whatever trying to get through another night. You're talking to somebody who's fresh and awake. And basically, I'm a little biased, but I'm Will Luongo. I'm an application support engineer at Ingenyard. And I really think that our support team is the dividing factor, the thing that separates us from a lot of our competition. And part of that is that you're getting access to this wide group of experts in a variety of different things. We have some systems administrators that are specifically, like that's the thing that gets them excited. They're looking at getting a new AMI as totally exciting to them. And then you have other people who know what AMIs are, but don't really care as long as it boots up and my notes are gone. So we also have a DBA team. We have people who are Rails developers that have come into DevOps that way. We have Linux administrators that have come into DevOps that way. And so we have kind of this melting pot of expertise. And we make it really, really easy for our customers to get in contact with that melting pot. Whether you're more of an IRC person or you want to talk to somebody on the phone, you can do that. Most of our stuff is through tickets, through emails and desks, that kind of thing. But you do have those other options. So when you're in the middle of scaling your staging environment and something is going wrong and you don't really know what, maybe you don't want to sit with somebody on the phone, but you want to be able to pop into IRC and just get a hand, you totally can do that for you. I'm just going to put my password in real quick so I can open my notes. Sorry. So that part I guess I didn't plan very well with the sleeping. So that's some of the things that our support team really brings. And we have kind of this mantra or this motto as a support organization, whatever it takes. And I should have brought it. I didn't do any slides because pretty much everything that's like a bullet point is on our website. You can go on our website and look at like the different tiers of our support. But one thing that I should have brought because you can't see it on our website is we have this picture from one of our support team meetups where we have all of us, well not all of us, but all of like our team leads. We're in a hot tub. And it was at like Tahoe. So it's at the ski resort and it's snowy. And so we actually got a picture of all of them sitting in a snow bank in their swimsuits. And then we captioned it whatever it takes. And that's kind of just, we don't actually sit in snow banks in our swimwear. But what we do is we will, you know, we care very deeply about getting your application up and running this not maybe not quite as much as you do because obviously, you know, everybody cares about their own thing the most. But we really do care. We're a very caring group of people that when your site goes down, we're distressed for you. We want to get it up just as quickly as you do. And, you know, not to say any names or anything, but I know that other competitors that we have, when you have something going wrong, you're kind of on your own. And maybe you'll get an email someday, but you can't just pop into IRC. You can't just, you know, call somebody on the phone and immediately have an expert base working with you that's already familiar with your stack and ready to go. And that's really, I think the biggest differentiation. So I will go a little bit into kind of the specifications of our support offering. Again, all of that is on the website. You can find it at engineer.com. But so we do have a tiered support model. And when you come in, as a trial customer, you can have 500 free hours or the first month, whichever expires first. And during that time, your primary point of support contact is going to be the Panda team. Unfortunately, I don't have a cool title. And so it's kind of like a rubbing point because I'm envious. But they have a cool title. They're the people that are going to help you, you know, learn the ropes, get used to clicking through the UI and how do I find this thing? How do I do that there? That's going to be them. You still have access to all of the other support staff as well, but your first point of contact is going to be the Panda. And then we have three other tiers. And there is Standard, which is the same people. All of them are the same people, regardless of which tier you're at, Standard, Premium, or Managed Support, you're getting the exact same tax. The big difference is going to be the time frame in which that you can access them. So with Standard Support, it's six to six your time. So if you're in, you know, an Asian Pacific time zone, then you would have six to six support your time. And then, you know, technically we don't, but there's the thing where we'll do whatever it takes. So a lot of times, even when you have an urgent thing that's out of your support window, we're still going to help you, assuming that, you know, there's not a higher priority issue. We have the Premium 24-7 semi-proactive support. And with that, we'll even watch your website for you, not personally, but we have a V-Knock or a Virtual Network Operations Center where we will receive alerts and notifications on your behalf that it doesn't just check to see if your application is, you know, responding on Port 80, right? What we'll do is we'll actually check a page that you specify and make sure that it's serving the content that you expect. And if it's not, then it alerts us with the Premium plan. You get this active notification and probably by the time you notice it, definitely by the time that you get a notification from us, one of our application support engineers is already logged on to your instances and actively working on getting your application back up the way that it's supposed to be. And then we also have recently added a new tier called Managed, which is all of the above, but it is even more proactive. So in addition to all of the things that we would do with the Premium where we're monitoring your website, we'll actually be doing regular audits to see, you know, what your upgrade schedule should be, that kind of thing, keeping you in the loop about opportunities to improve efficiency or maybe cost-effectiveness. And so we do have a pretty wide variety of support options, but they all boil down to the same expertise and the same level of care that, you know, we're basically allocating toward each and every one of our customers, regardless of their support level. And that's pretty much what support is about, I think. Cool. Don, that's the end of our talk. So if you guys want to have questions, go ahead and fire away. Thanks for coming, guys.