AEM Podcast: “AEM for the Cloud” – Hosting AEM in Amazon Web Services

button1When migrating to a new infrastructure, you’re probably considering whether a move to the cloud is right for you. While there are strong advantages to adopting Infrastructure as a Service (IaaS), there are risks as well. A misconfigured cloud infrastructure can result in the perfect storm of bad decisions: a more expensive hosting bill giving worse performance.

Bringing Together AEM & Amazon Web Services

When Adobe wanted to migrate from Drupal to AEM, it selected Axis41 as its partner for the implementation. We were able to bring both Adobe (AEM) and Amazon (the AWS cloud) together to benefit, just like we have for many other customers.

A Cloud Hosting Blueprint

In this new podcast and white paper, Adobe Certified Expert Joey Smith takes us through the rough outline of an initial approach to your cloud hosting needs. While there are options we can tune one way or another to meet your site’s unique needs, this blueprint defines the ideal starting point. You can also check out Joey’s blog post, where he goes into more detail.

Music Intro: Code Monkey by Jonathan Coulton


Announcer: Welcome to the Adobe Experience Manager Podcast, a weekly discussion regarding Adobe Experience Manager (formally CQ) and other marketing and technical issues. This podcast is presented by Axis41, your partner in Adobe Experience Manager implementations. Your hosts for the podcast are Joey Smith and Peter Nash.

Peter Nash: Good afternoon. Hi, I’m Peter.

Joey Smith: And I’m Joey.

Peter Nash: Welcome back everyone. I hope you doing well out there. This week, we’re going to discuss some of the server side things of Adobe Experience Manager. Specifically with EC2, so it is just going to be Joey and I, and don’t worry. We are well covered in this department, because Joey has been doing this for about 15 years now.

Joey Smith: Yeah, about 15.

Peter Nash: He has been a server and system administrator. So, why don’t we just jump in right into it and start off with, what is EC2 and why do we here tat Axis41 use it?

Joey Smith: So, EC2 is short for the elastic compute cloud. It’s an Amazon web services product that allows users to rent a virtual machine hosted inside of Amazon’s network architecture. As a networking tool or a server administrative tool, it becomes a really powerful force multiplier.

As a system administrator, I need to be able to scale things up or down with just a short amount of notice and EC2 and allows me to do that. For instance, with just to a handful of commands, inside the EC2 environment, I can add a new server and that only takes a few minutes, where it might take several days to purchase, build out and deploy a server in an actual physical hardware scenario. Also, if I need to quadruple the throughput, I can do on one server, I can do that with just an EC2 command rather than having to shut the server down and add new hardware and then bring it back up.

It’s really appealing to Axis41, because as an agency that offers a full suite of services like strategically defining, creatively designing and intelligently deploying content for our customers, it allows us to focus on our core competency on the aspects of the customer needs that have to be tailor-made and leave the actual physical administration of servers to somebody else.

Joey Smith: Okay. So, how do we actually use EC2 with Adobe Experience Manager?

Peter Nash: Well, for Axis 41, we have a few goals that we’re shooting for with our customer hosting. Like being highly available. We want to make sure that the website is up as much as possible for the customer.

Joey Smith: Yeah, up time is with everybody is going to be a huge issue, but for us that is our number one goal.

Peter Nash: Yeah. We also want to offer a really good loading experience. One of the things that cause people to lose the most customers is having a long load time on their website. I think Amazon at one point figured out that trimming an extra one second off of their load time lead to an increase in retention by like 50% or something like that. So, being able to get the content off the server and into your browser as fast as possible is another thing we focus on.

The third thing is the authoring environment. So for the people who are the Adobe Experience Manager authors, we want them to have a really good experience as they come in and design content. Now, there may be times where you have just one guy who is authorizing, there may be times where you have 10 people who are authoring and we are trying to build the solution that scales correctly and flexes to the number of people you have authoring at any given point in time.

And then the last we really try to focus on is if there is a catastrophic failure. If server completely gets deleted, somebody typed the wrong command into the wrong window or whatever the cause is, we want to manage between having the content available for the end user as fast as possible, but not losing anything in the Adobe Experience Manager authoring environment and those are the kind of constraints that work against each other in your backup and recovery system. And so, we’ve had to find the appropriate balance between those two.

Peter Nash: Well. Okay. So, why don’t you talk a little bit about how we have things deployed on some of the sites that we host then?

Joey Smith: Well, we generally take an approach that requires about seven different virtual machines in the EC2 architecture. This is an ideal deployment scenario. Some customers may need more, some customers may need less. This is the baseline that we start from and then we try to scale it and cut and paste to match the customers needs. So, we have two author instances. We have two published instances, two dispatchers and all of that running behind in elastic load balancer. The author and publish instances, we generally recommend that you run them on a large instance.

Peter Nash: I don’t necessarily understand everything about what all of those fancy words mean. I think you used the m1.large? Maybe you could walk us through what each of those things mean and why we’re using that type of architecture as kind of like a baseline?

Joey Smith: Okay. So, the m1.large instance is the virtual equivalent of a dual CPU server with about 8 gigabytes of RAM in it. Because it is a virtual machine and there is no physical hardware tied to anything. These are very rough approximations, but that’s generally what you are looking at. We recommend those for the author and publish instances, mostly because you need a descent IO (input-output channel), but you also need a lot of RAM. So, there are EC2 instances that have more RAM in them, but they don’t generally provide the nice disk, what they call EBS or Elastic Block Storage, back to storage unit and then there are smaller disk backed units, but they don’t have as much RAM. This is what we felt was this nice soft spot right in the middle of the offering that EC2 has out there.

I mentioned the elastic load balancer, that’s kind of an a cool device that Amazon makes available that you can put multiple EC2 instances behind it, all the requests come into it and it decides how to balance those among the different servers that you have in your architecture. So, if you were to add additional dispatches, then it would know that and it would be able to spread the work load more evenly if you are having a problem with the workload on the number of dispatches you would initially deploy.

Peter Nash: So, essentially it is a way of helping to balance out all of the different users that are trying to hit the servers and say, let’s give an even distribution, so that one is not being hit more than another and potentially having the server actually go down. Is that right?

Joey Nash: Certainly, yeah. And in the dispatcher environment, we actually like to use, what they call EBS optimized instances. And this is an offering that Amazon has. It’s a newer part of their stable of products that they offer and what it does is, it allows you to guarantee the throughput between the disk and the server. So, with these virtualized instances, the disks are not actually physically in the machine, it is all network based. And so, we are asking Amazon to guarantee a certain level of throughput between the disk, the virtual disk and the virtual machine, so that the responses that are cashed, that are coming out of the dispatcher, are coming through as fast as possible. We don’t need that in the CQ environment where the CRX is going to take care of some of that consistency and making sure that the rights go through. Instead in the CQ environment, we need that higher memory because the CRX is a bit of a memory hog.

The nice thing about doing this architecture that we’ve talked about here with two dispatchers, two authors, two publishers, is that we get to focus on all these things we talked about earlier, availability, reliability, being recoverable and giving good performance. An example of one of the things that this architecture allows us to do is, if we needed to fix something on one half of the network, we can take that piece completely out of production, fix what is going on there, turn it back on and the end users never even have to know. There is no impact to them showing that something happened. So, it removes what they call the single point of failure. Now, obviously, because it’s all on Amazon, we do still have a single point of failure at the entire device level, at the provider level. And for a customer who was interested in even spreading that risk further, we have some options there. We just never had a customer that’s pulled the trigger so of speak on those options.

Peter Nash: Okay. So, is there anything else about EC2 that you wanted to mention today?

Joey Nash: Well, like I said, using Amazon to actually physically host the architecture, allows us to bring a lot of capability to the table as far as scaling to the customers’ needs without having to have a lot of the cost that if we were hosting ourselves that we would have to present in the customer. And in further podcast, I would like to cover how we do backup and recovery and how the EC2 environment makes that really, really powerful and useful for us.

And then, one of the things that we’re incredibly excited about at Axis41 is the new virtual private cloud. This is an offering just in March of this year Amazon announced. And this allows you to build out an entire customers’ environment where the devices themselves can talk to each other and they all know about each other and they are all hosted in one bundle, but they are completely separate from everyone else and that will allow us, we’re hoping further down the line, to offer an even better end user experience with the EC2 cluster.

Peter Nash: Okay, yeah, that does sound interesting. And from a project manager standpoint, discussing how we are going to handle recovery and backup is a really big deal, because no one ever likes to beyond the phone and say “yeah, we lost everything, sorry about that,” that’s just not a conversation anyone wants to have. So, I think would be really interesting to go over and discuss some of the ways that we are handling that and provide those as a resource for other people out there. Okay Joey, thanks very much for walking us through all of that.

Announcer: Thanks for listening to the Adobe Experience Manager podcast, brought to you by Axis41, your premier partner in Adobe Experience Manager implementations. If you have questions, comments, or something you would like us to cover, send an email to [email protected]