text:
Start building with Acquia Cloud Free
The 2015Gartner MagicQuadrant for WCM
We're HiringFeatured Position: Software Engineer -Test (Boston, MA)
Hannah: Today's webinar is: Constructing a Fault-Tolerant, High Available Cloud Infrastructure for your Drupal Site.
First speaking we have Jess Iandiorio, who is the Senior Director of Cloud Products Marketing, and then we have Andrew Kenney who is the VP of Platform Engineering.
Jess, you take it away now.
Jess: Great, thank you very much, Hannah. Thanks everybody for taking the time to attend today, we have some great content, and we have a new speaker for our Webinar Series. For those of you who attend meetings you know we do three to five per week.
Andrew Kenney has been with the organization since mid-summer, and we are really excited to have him, he comes to us from ONEsite, but he is heading our Platform Engineering at this point, and he is the point person on all things; Acquia Cloud specifically, he'll speak in just a few minutes.
Thank you, Andrew.
Just to key up what we are going to talk about today, what we want to talk about, is we want our customers to be able to focus on Web innovations, and creating killer websites is hard, so that's why we wanted to be able to spend all of the time you possibly can, figuring out how to optimize your experience and create a really, really cool experience on your website. Hosting that website shouldn't be as much of a challenge.
The topic today is designing a fault-tolerant, highly available system and the point of the matter is, if your site is mission-critical how do you avoid a crisis, and why do you need this type of infrastructure?
Andrew has some great background around designing highly-available infrastructure and systems, and he's going to go through best practices and then I'll come back towards the end just to give a little bit of information about Acquia Cloud as it relates to all the content he's going to cover, but he's just going to talk generally about best practices and how you could go about doing this yourself.
Again, please ask those questions in the Q&A Tab as we go, and we'll get to them as we can. For the content today, first Andrew is going to discuss the challenges that Drupal sites can have when it comes to your hosting, what makes them complex and why you would want a tuned infrastructure in order to have high availability. He's been able with the types of scenarios that would cause failure, how you can go about creating high availability and resiliency, talk about the resource challenges with some organizations may incur, and then you may go through practical steps in best practices around designing for failure and how you can actually do that and architect and automate the failover as well. He'll close with some information on how you can test failure as well.
With that, I'm going to hand it over to Andrew, and I'm here in the background if you have any questions for me, otherwise I'll moderate Q&A and I'll be back towards the end.
Andrew: Thank, Jess. It's nice to meet you, everyone. Feel free to ask questions as we go or we can just have those at the wrap up, and I'm more than willing to be interrupted though.
Many of you may be familiar with Drupal and its state as a great PHP Content Management system, but even with it being well engineered in having a decade-plus of enhancements, there some number of issues with hosting Drupal and these issues were always present if you're hosting in your own datacenter, or environmental server in, let's say, RackSpace or a SoftLayer but even more challenging when you're dealing with Cloud hosting.
The Cloud is great at a lot of things, but some of these more Legacy applications are very, very complex and extensive applications may have some issues which you can solve with modules, you can solve with great platform engineering, or you can just work around in other ways.
One of these issues is Drupal expects POSIX file system, this essentially means that Drupal and all that's filing the output calls were designed with the fact that there's a hard drive underneath the Web server, if not a hard drive in there, is an NFS server, there's a Samba server. There's some sort of underlying file system. This is not oppose to some new applications where maybe they're built by default to go store files inside Amazon [Espree 00:04:16] or inside Akamai NetStorage, or inside documented oriented database, like CouchDB or one of those databases.
Drupal has come a long way especially in Drupal 7 in making it so that you can enable modules that will use PHP file streams instead of direct app open … Legacy, Unix file operations, but there's a number of different version of Drupal and they don't all support this and there's not a lot of great file system options inside the Cloud. At the end of the day Drupal still expects to have that file system there.
A number of other issues are: Drupal may make … you may make five queries on a given page, you may make 50 queries on a given page, and when you're running everything on a single server this is not necessarily a big deal. You may have latency in the hundredth of milliseconds, when you run you're running something on the Cloud it may be the same latency on a single server, but now let's talk about you're running and even with the same availability zone in the Amazon you may have your Web server on one rack and you may have your database on a rack that is a few miles away within the same availability zone.
This latency, even if it's only one millisecond or 10 milliseconds per query it could dramatically add up. One of the key challenges in dealing with Drupal both at the scale of [horizontal 00:05:49] layer as well as just in the Cloud in general, it's how you deal with high latency MYSQL operations. Do you improve the efficiency of the overall page and use less dynamic modules or less … 12-way left joins and views and different modules? Do you implement more cashing? There are a lot of options here but, in general, Drupal still needs to do a lot of work in improving its performance at a database layer.
One other similar-related note is Drupal is not built with partitions tolerance in mind, so Drupal will expect to have a master database that can you can go commit transactions to. It won't have any automatic charging built in so if you move, let's say, the articles on your website, your article section may go down but you'll still have your photo galleries; your other node-driven elements.
Some other new-generation applications may be able to deal with the loss of a single backend database node, maybe they're using a database like a REOC or Cassandra that has grades, partition tolerance built into it, but unfortunately MySQL doesn't do that unless you're in familiar in charting manually. We can scale out Drupal and scale up Drupal to MySQL layer and we can have availability MySQL, but at the end of the day if you lose your MySQL layer you are going to lose your entire application essentially.
One of the other issues with Drupal hosting is, there's a shortage of talent, there's a shortage of people that have really driven Drupal at a massive scale. There are companies like … the economies of the world who are the Top 50 Internet site that's powered by Drupal, or there's talent that the WhiteHouse giving back Drupal, but there's still a lack of good, dev ops expertise in terms of selling that … an organization that runs hundreds of Drupal sites. How to go to deploy this either on your internal infrastructure in, let's say, a university IT department, or to go deploy it on a rack space or a traditional datacenter company?
Drupal has its own challenges, and one of those challenges is: how do you find great, either engineering operations, dev ops people to go help you with your Drupal projects?
Now there's a number of ways, and you're all may be aware. of how an application would die in a traditional datacenter. That may be someone tripping over a power cord, it may be you lose your Internet access or one of your actual upstream ISPs or you have DDOS attack.
Many of these also go from the Cloud, but the Cloud also introduces other more … complex scenarios or in a couple of scenarios. You can still have machine loss, Amazon exacerbated this by that machine loss may be even more random and unpredictable, so Amazon may announce that a machine is going to be available on a given day, which is great and probably something that your traditional IT department or infrastructure provider didn't give you unless they're very good at their jobs.
There's still a chance that at any given moment, Amazon machine may just go down, and may become unavailable, and you really have to introspection into why this happened. The hypervisor layer, all this … the hardware abstraction is not available to you, Amazon shields us, RackSpace Cloud shields us. All these different clouds shield you from knowing what's going on at the machine layer, or there may just be a service outage, so Amazon may lose a datacenter, RackSpace, just this weekend, issued in the Dallas region with its Cloud customer.
You never know when your actual infrastructure and service provider is going to have a hiccup. There may just be network disruption, this could be packet loss, this could be routes being malformed going to different regions different countries, a lot of different ways that the network can go impact your application, and it's not just traffic coming to your website, it's also your website talking with its main [cache 00:10:10] layer, talking with its database layer, all these different things.
One of the key points of Amazon Cloud specifically, is that its file system, if you're using Lasix Box storage, there's been a lot of horror stories out there about EBS outages have taken down Amazon's EC2 systems or anything that's backed by EBS. In general, it's hard to go have an underlying, like I said before, a POSIX file system at scale, and EBS' instrument technology, but it's still in its infancy. Amazon, although it's focused on reliability and performance for EBS has a lot of work to do to go and improve that, and even people like RackSpace are just now deploying their own EBS-like sub-systems with an open stack.
Your website may fail just from a traffic spike. This traffic may be legitimate traffic, maybe someone talked about your website on a radio program, or TV broadcast, or maybe you get linked from the homepage of TechCrunch or Slashdot, but traffic spike could also be someone that's initially trying to take down your website. The Cloud doesn't necessarily makes us any worse other than the fact that you may have little to no control over your network infrastructure, you do not have access to a network engineer who can go to point out exactly we are upstream and all these factors are coming from, and go implement routing changes, or firewall changes to do this, so the Cloud may make it harder for you to go control this.
Your control thing, your ability to go manage, your service in Cloud may go down entirely; this is one of the issues that crops up on Amazon when they have an outage. They may go all the way back so you can do anything. It may go down entirely and you have to be able to engineer around this and ensure that your applications will survive even if you can't go spin up new servers or go adjust resizing and different things like that.
Another way to system failure is that your backups may fail, it's either a network to go and do backups of servers and volumes and all these different things in the Cloud but you have no guarantee even when the API says that a backup is completed, that it's actually done. This may be better than traditional hosting but it's still a lot of progress to be made in engineering to go accommodate this.
In general, everyone wants to have a highly-available and resilient website, there's obviously different levels of SLAs, some people may be happy if the website can sustain an hour of downtime, other organization may feel their website condition is critical and even a blip of a few minutes is just too much because it's actually having financial transactions or just publicity if the website is down.
In general, Drupal specifically should be … your hosting at Drupal should be engineered with high availability and resiliency in mind. To do this you should plan for failure because that's in the Cloud, just know that any given time a server may die and you can have either the hot standby and process in place to go spin up a new server. This means that you want to make sure that your deployment and your configuration are as automated as possible.
This may be a puppet configuration, it may be CFEngine configuration and may just be the chef or a batch script that says, "This is how I spin up a new machine and install the necessary packages. This is how I check out my Drupal code from GitHub, but at the end of the day when you're woken up by a pager … due to a pager at 2:00 in the morning, you don't want to have to go think about how you built the server, you want to have a script to go spin it up, or ideally, you want to use tools to go have it scale over automatically; and so you actually have no blips.
Obviously, to have no blips means that you need to have this configured automatically. You should have no single points of failure, that's the ideal in any engineering organization, any consumer-facing or internal-facing website application have no single point of failures. In a traditional datacenter would mean having dual UPSs, having dual upstream power supplies and network connectivity; having two sets of hard drives in their machine, or having RAID, or having multiple servers, having your application low-distributed across … in regions … geographic regions.
There's lots of single points of failure out there. The Cloud abstracts a lot of this, so in general it's a great idea to run the Cloud because you don't have to worry about the underlying network infrastructure, you can actually spin a server up in one of the five Amazon East Coast availability zones, and you don't have to worry about any of the hardware requirements or the power, or any of those things. In order to have no single points of failure, it means you have to have two of everything, or if you due to the downtime have … you can use Amazon's Cloud formation along with CloudWatch to go quickly spin up a server from one of your versions and just boot that up that way, but definitely it's good to have two of everything, at least.
You will want to monitor everything, before I said you could use CloudWatch to go monitor your servers, you can use Nagios installations, you can use Pingdom to make sure that your website is up, but you want everything monitored, so your website itself is returning … Drupal returning the homepage, do you actually want to submit a transaction to go create a new node and validate that this node is there, using companies like Selenium.
Do you want to just make sure that MySQL is running, do you want to see what the CPU help is, or how much network activities there is, and one of the other things is you want to monitor your monitoring system. Maybe you trust that Amazon's CloudWatch isn't going down, maybe trusting Pingdom not to go down, but you probably won't trust the fact that if you're running Nagios and your Nagios server goes down, you can't sustain an outage like that, you don't want that to happen at 2:00 in the morning and then someone tells you on Monday morning your website has been down all weekend, and a good idea to monitor the monitor servers.
Backing up all your data is key for resiliency and business continuity, and ensuring that your Drupal Cloud system is backed up; your MySQL database is backed up. Your configurations are all there, and this includes not just backing up but validating that your backups are working, because many of us may have been in organization where, yes, the DBA did back up a server but when the primary server failed and someone tried to restore it from the backup someone found out that, oh, well, it's missing one of the databases or one of the sets of cables. Or, maybe the configuration or the password wasn't actually backed up so there's no way to even log in to that new database server.
It's a very good idea to always go and test all of your backups, and this also includes testing emergency procedures, for organizations have to have business continuity plans, but no plan is flawless and plans have to be continually iterated just like in software. The only way to ensure that the plan works is to go actually engage that plan and test it, so it's all of my recommendation that if you have a failover a datacenter, or you have a way to failover for your website, you will want to test that failover plans.
Maybe you only do it once a year or maybe you do it every Saturday morning at a certain time, if you can engineer out so there's no hiccup for your end users, or may be your website has no traffic at any given point in time of the week, but it's a great idea to actually go test those emergency procedures.
In general, there's challenges with Drupal management, and just the resource challenges. The Cloud tells you that your developers no long have to worry about all the testy details but are necessary to go launch and maintain a website. You don't have to have any operations staff to be more … invest in Hype. I think a lot of engineers always felt that the operation team is just a bottleneck in their process and once they have validated that their code is good, either versus their opinion or they're running their own system test, or unit test. They wanted to go just push that live and that's one of the principles of continuous integration.
The reality is that developers aren't necessarily great at managing server configurations, or engineering a way to go deploy software without having any hiccup to the end user client who may load a page and then there's an AJAX call that refreshes in another base so we want to make sure that there's no delay in the process, and that code doesn't go impact the server, and the server configurations are maintained.
Operations staffs are still very, very likely and you have to go plan for failure to go plan your performer process in reality. It's very hard to go find people that are great at operations as well as understanding an engineer's mindset, and so dev ops is resource challenge.
Here's an example of how we design for failure. Here at Acquia, we plan for failure; we engineer different solutions to different clients' budgets to make sure that we give them something that will make their stakeholders, internally and externally happy. We have multiple availabilities on hosting so for all of our managed Cloud customers when we launch one server we'll then have another backup server in another zone.
Drupal will replicate data from one zone to the other. If there's any service interruption in one zone it will go serve data from the other zone, so this includes the actual Web node layer, or the Apache servers that are serving the raw Drupal files includes the file system. Here we use Cluster effects to go replicate the Drupal file system from server to server and from availability zone to availability zone.
It's also the MySQL layer, we'll have a master database server in its region, or we may have a slave against those master database servers, but it's ensuring that all the data is always in two places and anytime there's a hiccup in one Amazon availability zone it won't impact your Drupal website.
Sometimes that's not enough. There's been a number of outages recently in the Amazon's history where maybe one availability zone goes down, but due to the control system failure, or due to other issues with the infrastructure there's multiple zones that are impacted. We have the ability to have multiple region-hosting, so this may be out of the East Coast, and the West Coast, U.S. West, and maybe the … our own facilities.
It really depends on what the organization wants, but the multi-region hosting gives businesses the peace of mind and the confidence that if there is a natural disaster that wipes out all of U.S. East, or if there's a colossal failure that's a cascading failure in the U.S. East, or one of these different regions that your data is always there, your website is always in another region, and you're not going to experience catastrophic delays in bringing your website up-to-date.
During Hurricane Sandy there were a number of organizations that learned this lesson when they had their datacenters in, let's say, Con Edison's facilities in Manhattan and maybe they're in multiple datacenters there, but it's possible for an entire city to go and lose power for, potentially a week, or to have catastrophic damage by water to the equipment. It's always important to have your website available for multiple regions and we offer that for our clients.
One of the other key things … since they are to prevent failure is making sure that you understand the responsibilities and the security model for all the stakeholders in your website. You have the public consumer who is responsible for their browser and them engaging with them and showing they don't distribute their passwords to unauthorized people.
You have Amazon who is responsible for the network layer for … during that two different machine images on the HyperVisor don't have the ability to go disrupt each other. Making sure that they are … the physical medium of the servers and the facilities are all locked down and that customers using the security groups can't go from one machine to the other, or have a database called on from one rack to the other for different clients.
Then you have Acquia who is responsible for the software servers to the platform as a service layer with Drupal hosting. We are in charge of the operating system patches, we are in charge of configuring all of the security modules for Apache and in charge of recommending to you that you have Acquia network inside tools that you need to update … you need Drupal modules to ensure a high security, and you do all these things, but that brings it back to you. At the end of the day you're responsible for your application, your developers are the ones that go and make changes too and implement newer architectural things that may need to be security tested, or that choose not to go update a module for one point of view or another.
There's a shared security model here which covers both security availability in compliance, there may be a Federal customer who has to have things enabled a certain way just to go comply with a [FISMA 00:24:23] or Fed ramp accreditation. Obviously security can go impact the overall availability for your website and you don't engineer for a security up-front them half of them can go take down your machine or they'll compromise your data so you don't want your website back online until you've validated exactly what has changed.
What's very important to understand in the shared security module, and as you're planning for failure. Another thing I had briefly touched before was monitoring. This includes both monitoring your infrastructural application as well as monitoring for the security threats I just mentioned. At Acquia we use a number of different monitoring systems which I'll go in detail in, including Nagios, including your own 24/7, 365, operation step, but we also use third party software to go scan our machines to ensure that they are up-to-date and have no open ports that may be an issue, or have no demons running that are going to be an issue. Or have no other vulnerability.
This includes Rapid7, OSSEC, monitoring the logs, and for thwarting any … lots of issues across issues during security scans. It's important to monitor your infrastructure both from making sure the service is available as well as there's no security holes.
Back to monitoring, we have a very robust monitoring system, it's one of the ways … it's one of the systems we have to have, it's something we have 4,000-plus servers in the Amazon's Cloud, so all the Web servers and database servers and the Git and SVN servers, and all these different types of servers, they are monitored by something we call [Mon 00:26:01] Server, and these, on servers check to makes sure the websites are up, check to make sure that MySQL and Memcache is running, all these different things.
The mon servers also monitor each other, you see that from the line form mon server to mon server at the top, so they monitor each other in the same zone. They may choose to go monitor a mon server in another region, just to ensure that if we lose and entire region we want to get a notice about it.
The mon servers may also be the [height 00:26:32] of Amazon's Cloud, that we may go through rounding from someone like Rackspace, just to have your own business continuity, best-breed monitoring to ensure that if there is a hiccup or service interruption in one of the Amazon regions that we go and catch it. It's important to have external validation of the experience and if we … we may just use something like [Pingdom 00:26:50] in order to go ensure your website is always there.
Ensure that it is operating within the bounds of its SOA, so there's all sorts of ways to do monitoring but it's important to have the assurance that your monitored servers are working and each monitor that goes down has something else alert you that it's down, just so you don't impact your supporter operations team in trying to recover from an issue.
In pattern high availability resiliency in your monitoring infrastructure is very important. One of the other things; just being able to recover from failure; this includes having database backups; this includes having a file system, snapshots, so you can recover all the Drupal files, making sure that all your EBS volumes are backed up. Pushing those snapshots coming way over to [Espree 00:27:42], making sure that the process is replicated using a distributive file system technology-like luster. With all of this, you can potentially recover from catastrophic data-failure because having backups is important.
You can choose if you want to have these backups live, live replication of MySQL or the file system, or just hourly snapshots, or weekly snapshots, and that depends on your level of risk and how much you want to go spend on these things.
In terms of preventing failover, we utilize a number of these different possibilities, but you can use Amazon Elastic load balancers, multiple servers behind an ELB, and these servers can be distributed across multiple zones. For example, we use ELBs for a client like the MTA of New York, where they wanted to go and ensure that Hurricane Sandy wiped out one of the Amazon availability zones, we can still serve their Drupal website from the other availability zones.
We also used our own load balancers just in our backend to go and distribute traffic between all the different Web nodes, so one of the availability zone may go for request to the other availability zone, where you can do round robin, and that's a different logic in there to go to distribute the request to all the healthy Web nodes, and to make sure that any unhealthy Web node we cannot sent and travel too, so while our operations team are automating systems to go recover from the reason it's unhealthy.
We have the ability to also use DNS switch to take a database that's catastrophically failed or has other replication labs or something out of service. We always choose, at Acquia, to ensure that all your data transactions are committed. We'd rather have no data loss than incur a minimal service disruption, and so you're potentially losing, usually uploading the file or a user … and account being created or some other … we have people building software service business on top of us, so that loss and protection is very important to us, and so we utilize a DNS switch mechanism to make sure that that database traffic all flows to the other database server.
For the larger sites, multi-region sites, we actually use the manual DNS switch, to switch from region to the other, this prevents a flopping of an issue and having a cache server turned into something even worse, where you may have data written to both regions. The DNS switch allows us and allows our clients to build their Web site over when they choose to and then when everything is status quo again, they can go build back.
As I said before it's very important to test all of your procedures and this includes your failover process. It should be scripted so you can go, failover to your secondary database server, so you shut down one of your Web nodes and have it auto-heal itself. People like Netflix are brilliant about this, where they have their Simian Army as they call it, that they can go shut down RAM and shut down servers, and shut down entire zones and ensure that everything is recovered.
There's a lot of best practices out there in terms of actually testing the failover, and these failover systems and the extra redundancy that you've added to the [limiting 00:31:22] or points of failure is key and other non-disaster scenarios. Maybe you were upgrading your version of Drupal or you're rolling out a new module and you need to go add a new database or alter a cable, go through that process within Drupal.
You can failover to one of your given database nodes and then apply the [modular 00:31:44] schema changes to that node without impacting your end users. There's ways you use these systems and in your normal course of business to make sure that you use the available nodes to their full capacity and minimize the impact to your stakeholders.
Jess, do you want to talk about why you would to do everything yourself?
Jess: Sure, yeah. Thank you so much, Andrew. I think that was a really good overview, and hopefully people on the phone were able to take some notes and think about, if you want to try this yourself, what are the best practices that you should be following.
Of course, Acquia Cloud exists and as I'm in marketing I would be remiss not to talk about why you'd want to look at Acquia, but the reasons why our customers had chosen to leave DIY, they are mainly pocketed into these three groups. One is: they don't have a core competency around hosting let alone high availability, and so if that core competency doesn't exist it's much easier and much more cost effective to work with a provider who has that as their core competency and can provide the infrastructure resources as well as the support for it.
Another main reason people will come to Acquia is they don't have the resources or have no desire to have the resources to support their site meeting 24x7 resources available in order to make sure that the site is always up and running optimally, so Acquia is in a unique position to respond to both Drupal application issues as well as the infrastructure issues. We don't make code changes for our customers but we always are aware of what's going on with your site, and can help you very quickly identify the root cause of an outage and resolve it quickly with you.
Then one of the other reasons is it can be a struggle when you're trying to do this yourself, either hosting on premise and you have purchase servers from someone or if you've actually gone straight to Amazon or Rackspace. Oftentimes people have found themselves in between sort of blame game and a lot of finger-pointing if the site goes down, their instinct would be to call the provider and if that provider says, "Hey, it's not us, lights are on, you have service," then you have to turn around and try to talk to your application team, what's wrong, and so there can be a lot of back and forth, a lot to time wasted and what you really is your site up and running.
Those are reasons to not try and do this yourself, of course you're welcome to, but if you try and you haven't had success, the reasons you're going forward with Acquia is our White Glove service so, again, fully managing on a 24x7 basis for the Drupal application support as well as the infrastructure support, as well as our Drupal expertise, so we have about 90 professionals employed here at Acquia across operations, who are able to scale up and down your application.
We have engineers, we have Drupal support professionals, and they can help you either on the break-fix basis or on an advisory capacity to understand what you should be doing with your Drupal site between the code and configuration to make it run more optimally in the Cloud, so that's a great piece of what we offer. Of course all of the engines covered today in terms of our high availability offerings and our ability to create full backups and redundancy, across availability zones as well as Amazon Regions.
We are getting to the close here, if you have some questions I'd encourage you to start thinking about them and put them into the Q&A.
The last two slides here just showcase the two options that we have if you would like to look at hosting with Acquia, Dev Cloud is a single server self service instance, so you have a fully-dedicated single server, you manage it yourself and you get access to all of our great tools that allow you to implement continuous integration best practices.
This screen shot you're seeing here is just a quick overview of what our user interface looks like for developers and we have separate dev staging and prod environments pre-established for our customers, very easy-to-use drag and drop tools that allow you to push code files and database across from the different environments while implementing the necessary testing in the background, to make sure that you never have made a change to your codes that could potentially harm your production site.
The other alternative is Managed Cloud, and this is the White Glove service offering where we promise your best day will never become your worst day with someone playing traffic spike that ends up taking your site down. We'll manage your application and your infrastructure for you, our infrastructure is Drupal tuned with all the different aspects that Andrew has talked about. We've used exclusively Open Source technologies as part of what we add to Amazon's resources and we've made all the decisions that need to be made to ensure high availability across all the layers of your stack.
With that, we'll get to questions, and we have one that came in. "Can you run your own flavor of Drupal on Acquia's HA architecture?"
Andrew: The answer is, yes. You can use any version of Drupal and I think we are running Drupal 6, 7 and 8 websites right now. You can install any of Drupal modules you want, we have a list of which HA extensions we support. We support most popular modules out there. There's always been a day, maybe there is some random security module or some media module that need something and we may need to go sell it for you or recommend the alternatives. You can … people have taken Drupal and just … for lack of a better word, and just bastardized it, and just built these kind of crazy applications on top or we've written chunks of it, and then it also works with our HA architecture.
Our expertise is in the Core Drupal, but our professional services and our technical account managers are great at analyzing applications and understanding how to improve them in performance so by now we support pretty much any … the platform can host any PHP application, or static application. It's optimized for Drupal, but the underlying MySQL and file system and Memcache and all these different requirements for Drupal website; they are the AJ capabilities of that works across the board.
Jess: And we do have multiple incidents where customers have come to us, and they've got their application running and in our Cloud environment fine, but they came to us from hosting directly with RackSpace or Amazon and they found it to be either unreliable or it just wasn't cost-effective for them because of the amount of resources that had to be thrown at the custom code.
Another good thing about Acquia is through becoming a customer you can have access to all these tools that help test the quality of your code and configuration, so when you have extensive amounts of custom codes that are brought into our environment we can help you quickly figure out how to tune it and/or if there are big issues that are the culprit for why you would need to constantly increase the amount of resources you're consuming; we can let you know what those issues are and we can do a site audit through [PS 00:38:37] like Andrew mentioned.
Our hope and our promise to our customers is that you're lowering your total cost of ownership if you're giving us the hosting piece of it along with the maintenance, and if there's a situation for any of our customers where we are continually having to assign more resources because of an issue with the quality of your application; that's when we'll intervene, and suggest, as a cost-savings measure, work with our PS team to do a site audit so we can help you figure out how to make the site better and therefore use less resources.
Andrew: In a lot of cases we can just grow more hardware at a problem to go have that be a Band-Aid, but it's at both our best interest and the best interest from the customer in terms of both their [builds 00:39:17] as well as having an application that will last for many, many more years, to have our team recommend this is what you should not have done. This is how you can best use this module or this other recommendation to go have a more highly-optimized website for the future.
Jess: The question on, "Why did Acquia choose Amazon to standardize the software, Cloud, on?"
Andrew: Acquia has been around for the past four or five years and Amazon was the original Cloud Company, I was at the Amazon Reinvent Conference a couple weeks ago and one of the key agencies there said, "Amazon is number one in the Cloud and there is no number two." We chose Amazon because it was the best horse and the time, and we continue to choose Amazon because it's still the best choice.
Amazon is … their release cycle for new product features and new price change and all these things is accelerating. They continue to invest in new regions and Amazon is still a great choice to go reduce your total cost of ownership by increasing your agility and your velocity to go build new websites and deploy new things, and move things off your traditional IT vendor to the Cloud, and so we are so very, very strong believers in Amazon.
Jess: "Does Acquia have experts in all theirs … as a Drupal architecture across the data base, the OS, caching?" Then the marketing person is going to take a stab at this, where it's a [crosstalk 00:40:50]…
Andrew: We definitely have experts at all different levels. The RBS team may go and we have some Red Hat experts, we have some … a bunch of experts so they can go recommend different options, for people who don't host with us. Internally we are all gone to based-hosting so that that may be the expertise about operations staff. Database, we know we have operation staff dedicated just to MySQL. We have support contracts with key MySQL either consulting or software companies for any questions that we can't handle.
It's one of the ways that we go scale if you don't have to go pay at the corner of the world a 10 grand fee for something that we can just go ask them. Caching , we have people that have … help design some of the larger Drupal sites out there and live through them to be under heavy traffic storms, people that they may go contribute after Drupal Core caching modules, be it Mem-cache or regis-caching and all these different capabilities. With [Agar 00:41:56], we don't have to use Agar internally but we do interact with it and support it, a lot of our big university or government clients may be using Agar in their internal IT department and they may go and choose to use us for maybe some of the flagship sites or for some other purpose. Yes, we do have experience across the board.
Jess: [Ken 00:42:22], unless you have you any questions that you came in straight to you; that looks like the rest of the questions that we have for the day. Hopefully that you found this valuable, you've got 15 minutes back in your day, hopefully. You can find good use for that.
Thank you so much, Andrew, for joining us, I really appreciate it and the content was great.
Andrew: Thank you.
Jess: Again, thanks everybody for your time; and the recording will be available within 48 hours if you'd like to take another listen, and you can always reach out directly to Andrew or myself with any further questions. Thank you.
Andrew: Thanks everybody.
Speaker 1: Hi everyone. Thanks for joining the webinar today. Today's webinar is Creating Solid Search Experiences with Drupal, with Chris Pliakas, who is the product owner of Acquia Search.
Chris Pliakas: Today's webinar on creating a search experience with Drupal, I think we've done a lot of webinars in the past where we focused on Acquia Search, we focused on some of the basics. Today, I really wanted to focus on just Drupal in general, not having Acquia Search focus. Of course, all these techniques can be used with Acquia Search, but I just wanted to highlight some of the things that are in the community.
Also, based on our experiences hosting over 1,600 indexes, with 1,600 subscriptions, people who are experimenting with search pages and various UX talk about some of the trends that we're seeing, and in order to get the best experience possible, we wanted to touch on some content strategy items that you can employ to make sure that your search is set up for success.
Then we'll focus on the search page user interface, so we'll do a live demo exploring some of the tools that are available to Drupal right now that can be used to create modern-day search user interfaces so that your users get the best experience possible out of the application and could find content that they're looking for.
Also, we're going to demo some things that are coming down the pike. I think it's important to recognize that right now, enterprise search is at a crossroads, and I just want to distinguish for a minute what enterprise search means. When we talk about enterprise search, we're talking about internal site search, and enterprise doesn't necessarily mean large corporations. Enterprise simply means that that search is important to your business and important to you, so this isn't just a big business thing. This is for searches of any size.
But we see some trends that are emerging with external searches, searches like Google, Bing, Yahoo!, that are now going to be expected by users of your internal site search. Trends that are emerging in the search community at large, really, there is going to be an expectation that your search experience matches what's out there currently. It's pretty advanced things, so we'll talk about those trends and we'll talk about what's changing in this space specifically.
We talked about search is really evolving. Over the past 10 years or so, which is quite a long period of time, your internal site search really hasn't been much more than the user entering keywords and then displaying results that are pretty basic. You have a title, you have a snippet, that sort of thing. But really, right now, search is starting to move into a different space where we have to identify what the user is actually looking for and then display relevant results. Relevant results don't just mean keyword matching, meaning knowing things about your content, knowing things about your user to make some assumptions to present them with relevant results.
As we create more and more content on the Web today, it's getting harder and harder to sift through that data and display meaningful data. One thing that we'll start out with is just a simple example.
What I want to start out with is talking about Apple. How many people know Apple? All right, so I see some hands in the webinar. I guess I want to ask "How well do you know Apple?," so a first question that I want to ask you is, "Is Apple growing?" I'll let you answer in your heads. It's not really a good forum for answering in public.
The second question that you should think about is does Apple have money? Then the third question, is Apple multilingual? Does Apple support multiple, does Apple have knowledge of multiple languages? Does Apple speak more than just English? Those are the three questions that I want you to answer in your head.
I'm just going to assume that you guys did a good job and you were able to answer that. Based on those three questions, I think there is no doubt that we're talking about Apple Martin, who is the daughter of Gwyneth Paltrow and Coldplay lead singer Chris Martin. Apple Martin, like all kids, she is growing. Does she have money? Absolutely. I think her parents are doing pretty well; one is a rockstar; one is an actress. One useful tidbit is that she cannot watch TV in English, so she is getting raised as a multilingual speaker.
Is that the wrong Apple that you were thinking of? I'm assuming that it is. Tech audiences, let me say, Apple, usually think of the company Apple, and the problem really is about context. The first trend that I want to talk about is contextual computing. Right now, we start to see how Apple could mean different things. It could mean the fruit. It could mean the company. It could mean Apple Martin. It could mean Fiona Apple. It could mean a lot of different things.
When I talk about context, I mean the things surrounding it that expose the content for what it is. For example, if we are talking about Apple being a Fortune 5 company or a Fortune 1 company, whatever it is right now, then that context would expose Apple as being a company. If we were on a pop culture website, then it would be more likely that Apple is the daughter of Gwyneth Paltrow, like we mentioned.
Context and how it relates to your content is getting to be really important as we get more and more data. Sites aren't just displaying one thing now. Sites are starting to display lots of different pieces of content, and we need to start recognizing that simple keyword searches aren't going to serve our users. We really want our results to be relevant towards what people are actually looking for.
One way that we can do this is by search statistics. Search is a really unique tool in that it is a window to what your users are expecting on your site. By entering keywords and by clicking on various pieces of content, your users are actually telling you what they want from your website, and they are telling you what content they think is relevant.
There are things out there like voting or reputation metrics, but search is really the best tool to be able to extrapolate what people are trying to do with your website.
That also leads into structured data, which is another trend that we're going to talk about. Structured data is a way to actually denote what type of content you have on your site. Whether, again, we'll go back to the Apple example, is Apple the organization or Apple that's something else? These are the three trends that search is really rallying around.
I want to talk about what Drupal is doing right now to address this and some of the things that are going to be coming down the pike within the next six months or so, because it's important that as you start to build your search experience that you're starting to recognize some of these trends so that when the Drupal tools emerge, you can make use of them effectively and provide the site search that your users are coming to expect.
Now I'm going to go to the live demo portion of the site just to set the stage here. I have a really basic Drupal install. It's the standard Drupal blue that you see out of the box, and it has some prepopulated content. It has a couple of events, a couple of blogs. We'll actually build out some of the search experiences and identify some of the trends that we talked about.
Now that we have the site up, right now, I'm connected to an Apache Solr backend. Again, if you're connected to Acquia Search or you are connected to Apache Solr, I think there are demos soon that you can install Drupal. You can configure some of the basic modules. You can download, install the modules. We're going to start with that assumption that that's the level that we're at.
If you do need some help or if you are unsure as to how to install modules, how to configure modules, I do recommend that after this webinar, there are some great resources on drupal.org and some great articles that Acquia provides as part of its forums, part of its library that can help ease that transition. But you can still get some value out of this webinar by following along and taking notes of which modules are being used and seeing how you can configure them once they're installed.
First, what I want to do is I want to just execute a search. It's the same whether you're using core search or any other backend. But I'm going to search for DrupalCon, and we'll start to analyze some of the results to see what the default behavior is that you get out of the box.
The default behavior we'll see is somewhat useful but not really. But if I entered DrupalCon, it will give me the pieces of content that match that keyword. It will give me a highlighted results snippet, and it will show me a little bit of information in terms of who the user was that posted that content and what date that content was posted. Sometimes, that's useful. Sometimes, that's not. But again, this is a basic search interface that you get out of the box.
To be perfectly honest, this isn't very useful. This isn't what users expect. If you compare it to Google or Yahoo! or Bing or all the other major players out there, this is weak, and it doesn't really give users the information that they need to effectively search the content of your site.
The first thing that I want to do is I want to explore something called Facets. And facets are filters that users can apply to help refine the search results, and it also gives some aggregate information such as the count or number of results matching that filter based on the keyword that you entered.
The first module that I want to explore is something called the Facet API module. I'm going to go to the project page here. This is a module that works with core search. It works with Apache Solr search integration. It works with Search API if you're using that module. It's a way to configure your search interface regardless of what search backend that you're using.
If I expand the screenshot here, you'll see that here are some examples of the types of facets that you can have. You can have facets by content type, by date. There are even some interesting contributed modules out there that allow you to display facets as graphs. You can really control the interface and display things in pretty interesting ways.
I'm just going to scroll down and show some of the things that you can … some of the add-ons that are available that you can make advantage of. Again, we have the graphs that we talked about. We have a slider, so if you have numeric facets, numeric content, you can say, "I want to show data between this range," tag clouds, and also date facets, which we'll actually explore and configure.
I'm not going to spend too much time. That's just an overview to whet your appetite for what's out there and what's available in the Drupal community. But I do want to just go and start configuring this so you can see what this looks like and how this works.
The first thing that I want to do is I want to be able to filter this by the content type. I do have two content types here, blog and event, so I want people to say, "Okay, if I'm searching for DrupalCon, I want to filter by the blogs or I want to filter by the events that I want to see," so that you can get the relevant information for you.
First thing I'm going to go do is configure the Apache Solr Search Integration Module. That's the one that I'm using. I'm going to go to Apache Solr, going to go to Settings, and I am going to go to Facets. These are the lists of the facets that I have available to me. First thing I'm going to do is configure and enable the content type. I'm going to save this configuration.
Now that facet is saved, I actually have to position it on the page. The default facets are blocks. Blocks in Drupal are small pieces of content that you can position in various regions or various areas on a page. Once you enable a facet, there is a link up top that allows you to go directly to the block configuration page so that you can configure this immediately.
If I click on Blocks and scroll down … it's actually enabled for me. I'm just going to reset this so that it is where you guys will see it when you start from scratch. But it will start down here in the disabled category. These are all the blocks that are disabled. We look for Facet API, the backend that we're using, and then content type. This is the facet that we just enabled.
I'm going to position this in the first sidebar. It is recommended that you do position it in the first sidebar, so that will be on the left-hand side. The reason is because that's where most of the major search engines position their facets, so in order to help people navigate your search page, we use expected patterns. That's the best place to put it so that they don't have to hunt around for it.
I'm going to save my block. Now I'm going to go back to my search page. I'm going to search for DrupalCon. Now I have a facet up in the upper left-hand corner that allows me to filter by events or by blogs. If I filter by blogs, it's reporting that I have two results. If I click that, you'll see that I do get my results filtered to the blog that I want. That's pretty basic stuff, but it allows your users to actually target what they're looking for.
The next thing that I want to discuss, this is very basic, facet configuration. The next thing that I want to discuss is a pattern called progressive disclosure. This is something that you'll see on Amazon where if you go to Amazon's search, you'll see that you'll be prompted to search for something that you're interested in, whether it's one of the products that they have. Then when you search on that product, you'll be displayed different filters based on the different types of things that are returned. What it prompts a user to do is start out small, like selecting the department that they want to search in, and then based on that department, it will expose different filters or facets that are relevant just to that.
I do want to take a step back and talk about the events. The events that I have on this site have dates that are associated with them, so the date that the event actually starts, whereas the blogs have a different type of date. They have the date that the article was posted.
When you're searching for events, you don't really want to know the date that the event was posted. You want to know the time that the event is actually happening, so you're going to have two different types of date facets, depending on the content that you're targeting.
Instead of displaying all of that information, all the possible combinations of facets on the left-hand side, we want to only display the facets as we start to navigate down the content types that we're interested in.
To highlight this, I'm going to go back to the configuration page, and I'm going to go to Apache Solr, and I'm going to go to Settings, configure my facets, and I'm going to scroll down. We're going to see two types of date facets that I was referring to. One was the post date and one was the event date. I'm going to enable both of these. I'm going to go to my blocks, position them. I'm going to scroll down, and now I see that the new blocks are here and disabled, so I'm going to position them in the sidebar first, like the other. I'm going to make sure that they're in the correct order that I expect.
I'm going to save these blocks. I'm going to go back to my search page, search for DrupalCon. You see that by default, now I have filter by post date, filter by event date. In order to configure this progressive disclosure pattern, what we're going to do is leverage something in Facet API called Dependencies. Instead of just explaining, I'm just going to go for it and highlight by example.
When I mouse over the facet, I get a little gear in the upper right-hand corner. If I expand that, I have an option to configure facet dependencies. This is the date that the actual content was posted, so again, it makes more sense for the blog than it does for the event. The first option that I have here is bundles, which are synonymous with Drupal content types. I'm going to say at least one of the selected bundles must be active. I'm going to say I only want to show this for blogs. I'm going to save this and go back to the search page.
Now you see that that date facet is gone. If I click on blog, now it appears. Now filter by post date. Again, I'm only shown, I'm only displayed facets that are relevant to the content type that I'm looking for.
Again, I could do this filter by event date. Again, mouse over the gear. Click Configure facet dependencies, Bundles. At least one of the bundles is active, and I'm going to say Events.
Now I go back, and when I search for DrupalCon, I'm going to start off very small, limited options, kind of guiding your users to select something and refine their results. As I click on blog, we know that we're in the blog context, so again, context meaning information that is used to determine what type of content you're viewing. Now that I know that I'm viewing blogs, I see the post date, which is a little more interesting.
Whereas if I click on the events, now I get the filter by event date. I can say, "Show me events that start in August of 2012 or May of 2013." It's not going to really target the type of events that are relevant to me.
One thing too, I'm actually going to go back to the blog facets, you see here that for the blogs, we have this drilled down thing that starts … we have a couple of blogs that span a couple of years, and the default facet that's coming out of the box, you have to actually drill down to 2011. Now I'm going to go in March. Now I'm going to go March 21st. It allows you to drill down by the specific date all the way down to the time. But that's actually not what users expect when you're dealing with types of displays that are blogs, that sort of thing.
I'm actually going to go to Google and search for Drupal blogs. If I click on Search Tools, we'll see anytime they don't have that type of drill-down. They actually have the ability to refine by a certain range. That's usually what users expect, and that's a use case that people commonly ask for that we've seen in our support requests.
The next module that I want to explore is called the Date Facets Module. Again, this is available on drupal.org, date_facets. This can be linked to by the Facet API project page. But again, if we look at the screenshot, we'll see that it provides a nice little display widget that allows you to display your facet in the range selection. We're going to assume that that module was downloaded.
Click on Modules. Once you download that module, you're going to install it. I'm using the module Filter Module to provide this nice interface where I can make sense of my modules because anybody that builds Drupal sites know that you can get up to hundreds of modules, so you need to be able to filter them more easily in this Module Administration Page. All I have to do, I already enabled this, but if I select the check box, click Save configuration, that's all I need to do to install the module.
Once the module is installed, actually, I'll do this from the search page, again, filter by blog, you have an option with facets to configure the display. If I mouse over the gear and click it, same list of options that allow me to configure the facet dependencies that can configure the facet display.
After I've installed that module, I'm going to have a new display widget site. If I expand here, you can see up at the top there is a new date range widget. The type of display in Facet API is called the widget.
If I click on date range, I'm going to click Save and go back to search page, I'm actually going to get an arrow here, which I wanted to highlight purposely. It says the widget does not support the date query we typed. When you're doing the date range, this is a common error that people report. You have to actually scroll down and select the different query type. This just tells Drupal that we're not just doing the date filter. We're doing the actual ranges.
I don't want to get into the technical aspects of it, but behind the scenes, it actually changes the type of filter that the backend uses, so it's important that we actually make this distinction.
Now if I save and go back to the search page, now you see that I get filters that are very similar to Google. I can refine things by the past week, which I have nothing, or past month, past year. It looks like I only have stuff within the past year. But it was able to refine that based on the time range of the content that you have, so it really allows people to narrow down the things that are more recent.
Those are a couple of the tips that I wanted to share regarding the fast configuration, but I want to stop and see if there any questions before proceeding. Do you have any questions? All right. We'll move on from facets.
The next thing that I think is pretty interesting is that instead of having a unified search page which displays all the content across your entire site, sometimes it's useful to actually have targeted search pages. These are things like, okay, I have a blog section on my site, which we have here. I only want to search across the blogs or I don't want to make the user actually click on blog to refine the results. This can actually be done in the Apache Solr Search Integration Module, which we're going to focus on.
I'm going to click Configuration then go to Apache Solr Search. One thing that I'm going to do to simplify this demonstration and something that I think is useful in Drupal in general is Drupal 7 provides this nice little shortcut functionality. You see here I have Apache Solr Search with a little plus sign. I can click this and it will now add this configuration page, a link to this configuration page in the toolbar so that I can navigate to it more quickly as opposed to having to go through the normal path. I'm going to do that for an easier demonstration. If you're configuring your search pages, you might want to do that as well.
Some of the tabs here, we have one that's geared towards pages and blocks. I'm just going to select pages and blocks. This is where we can actually manage search pages. I'm just going to go ahead and add a search page and we can see what this will do.
The goal here again is to create a search page that just narrows down your blogs. I'm going to say this is a blog search. I'm going to scroll down. I'm going to make sure that my correct environment is selected. In this case, I'm running Solr locally, but if you're connected to Acquia Search, you'll have an environment for Acquia Search. Environment is really named for the backend that you're connecting to.
Again, in title, search blogs. That's going to be the title of the page. The path, I'm going to put in search/blogs. The part that's going to allow me to filter just by blog content is this part at the bottom, custom filter. It's a little complex in terms of how you do it, but first, I'm going to select that custom filter check box to make sure that I'm using a filter. We're going to read the description down here. It says, "A comma-separated list of lucene filter queries to apply by default."
In English, what that means is lucene is a very low-level search engine that Solr is built on, but it's a syntax that allows you to filter by specific things and do some pretty interesting stuff. The very basic part of lucene syntax is if you want to filter by field, it will be the field name, field and then colon value. We have this use case actually down here in the comments. We see here bundle:blog. Bundle is the actual name of the Solr field, and blog is the name, is the value that's actually stored in the index.
If you want to see all the fields that are stored in Solr, you can actually click Reports and click on Apache Solr Search Index. These are all the different field names that you have at your disposal. It doesn't show you the values, but in our case, we know that the bundle will index the machine-readable name as we specified when we created that content type. If I go to structure content types, we see here all the different machine names. Blog is just the machine name, with _blog.
Again, I'm going to match the Solr field to this machine name. I'm going to say bundle is the name of my Solr field, and then blog is the value that we want to filter by. I'm going to save this page. Now, I have a search page that's dedicated just to blogs. I'm going to click on this. If I say DrupalCon, now we see that it only gives me two results because it's only filtering by the blogs, not filtering by any of the events.
Sometimes, it is nice to have these targeted searches. For example, if you do have a blog section of your site, it is very nice so that you don't have to actually set up a separate site for your blog. You can have your blog be a micro-site that is under the same Drupal installation but just has different configurations isolating that content so users can find what they are looking for.
I want to stop there and see if there are any questions on the search pages. No? We're good? Okay. I'm actually, just to reduce the noise here, I'm going to disable … is there a question?
Speaker 1: Yes. Is there an autocomplete module?
Chris Pliakas: Yes, there is. Let's see if I can find it. Yes. The module name is aptly named Apache Solr Autocomplete. The project name is Apache Solr_autocomplete. This will provide the type of autocomplete functionality that people are used to.
Now, it is important to note that, and this is one of the trends that we're going to talk about, that this actually pulls off your index and does keyword matching. But as you have larger sites and more data, then sometimes, keyword matching isn't necessarily the best option to guide people towards relevant results. There is a trend that's going to match statistics as well so that you can actually autocomplete based on what people are searching for as opposed to just the keywords which theoretically will guide them towards more relevant results. As I talk about the Apache Solr Statistics stuff that we're doing, we'll relate that back to the autocomplete.
Speaker 1: We have a few more questions.
Chris Pliakas: Okay.
Speaker 1: Can that custom search be put in a block?
Chris Pliakas: Can this search be put in a block? Yes, I believe it can. Let me just search for a module. I believe there is a module that does this. I want to see if this is what it does. I might have to get back to you on that one. I believe there is actually a module that does allow you to expose your searches in a block, but I'm not 100 percent sure on that, and so I'll take that as an action item and post that answer after the webinar is over.
Speaker 1: Okay. Also about the statistics stuff, is that available now?
Chris Pliakas: Yes. There is an Apache Solr Statistics module that does some very basic stuff, but it's more geared towards administrators. It does things like the keywords, but it does so more or less how many times a search page is viewed, which isn't really that useful to site builders. But there is a new extension to that module, a new branch, I guess I should say, that is available on the community. I'll show you where it exists and I'll give you a bit of timeline about when that is going to get merged back in, but that's more geared towards site builders and talks about how people are actually using your search.
Chris Pliakas: All right. I'll take it …
Speaker 1: All of this work with non-Drupal content if some other system populates parts of the Solr index?
Chris Pliakas: The answer to that is yes. The trick is getting that data into Drupal. There are some example code, which we'll point to the links after the webinar, that allow for more easily getting content into Drupal. But once you get the content in, you can display facets and that sort of thing.
The display of the search result doesn't really bias towards what type of content it is. Again, it's more or less just getting that content into Apache Solr in a way that Drupal can recognize.
Speaker 1: We have one more. Where is the extension to have autocomplete?
Chris Pliakas: Again, that's the … we'll do it for Google. If you search "Drupal Apache Solr Autocomplete," I'm going to venture that it is one of the first results. It's on drupal.org. The URL is drupal.org/project/apachesolr, all one word, _autocomplete. It's pretty easy to find on drupal.org and it's available on this project page.
Okay. I'm just going to clear cache just to make sure that our stuff is gone. I'm actually going to go back to Google here.
If we look at Google, we see that the search results are displayed in a format that's pretty familiar to us. Let's go to Yahoo!, or let's go to Bing. Search for Drupal.
Now pretty interesting, you'll actually see that the search results are very similar. You have the title. You have the URL. You have the snippet, and you have some additional information about it. Third thing, go to Yahoo!, search for Drupal, and we'll see that again, different results are returned because they have different algorithms that determine the relevancy, but the display is very, very similar. The reason is because there is actually a lot of standardization that was done in 2011 by Google, by Bing, and by Yahoo! What that is is something called schema.org.
Let's go back to Google, and we'll look at the search results. Let's go to our blog. We see some interesting things here. We see that when we search for our schema.org blog, you scroll down, we see one of these results has an image. This is actually a great way to talk about schema.org in that it provides some structure around your data.
When we build content types and manage fields inside of Drupal, we're actually just configuring the data model, so that's the underlying buckets that we put data into, and it doesn't really have any meaning beyond what we name it. Google doesn't understand when you create a blog content type that that's actually blog content. It's only blog in name only. Or when you create an event content type, it's only events in name only. That's almost like Drupal provides you a leg up in that you don't have to build your database but that you can do it through the UI. But I'll actually go back to Drupal here, click Structure, click Content Types.
You see here that I have events. If I manage my fields and I added some extra data here, the date, the event date, an address, an image, if I wanted to add another field, what you do is you create your label and then you select the type of field that you want. We see we have date, file, we have text. This is all real basic stuff that again is just really low level and doesn't actually expose what type of content that is.
Schema.org is the layer that sits upon that which says, okay, this text field is actually an address, or this image is the primary image of this piece of content, or this event date is the actual start date of an event. It will actually go up as well and say, okay, you can say this content type event is actually an event so that it can be recognized by some standard that's out there that's agreed upon by the major search engines.
This actually helps your Drupal site by not only when Google and Bing and stuff index your site, it will actually read this metadata, but there is actually some work that's being done so that it can modify the display of your internal search so that users are presented with a familiar experience.
That's probably the thing that people will recognize the most, but the module that I want to share with you is called the Rich Snippets module. We'll actually just install it and see what it gives us out of the box. Again, Rich Snippets, rich_snippets. There is another module that's similarly named, but it's important to understand that this one is geared towards your internal site search.
This takes that schema.org metadata and actually will format your results accordingly. I'm just going to install this module and see what it gives us, and then we can break it down a little bit.
Again, I'm going to go to Modules. I'm going to go to Rich Snippets, enable this. I'm going to bring up a page here so that we can see what it looks like before. Again, very blah. Now, when I enable the Rich Snippets module, we go back to my search page. I'm going to refresh the page. Now you see that it displays the results very, very differently.
The goal of this module is to work fairly out of the box. With Solr, you might have to re-index your content. But as you can see, now the results are displayed in a way that's much more friendly and much more in line with what users expect.
As a nice UI tip, this module is going to emerge as something that's going to be a staple on sites with search. As you can see, for DrupalCon Portland, DrupalCon Munich, it displays a little image, and it also displays the start date.
Now, for the blogs, it displays who that blog is by and when it was posted. As you can see, based on the context or based on the schema that we've assigned to it, the search results are displayed very differently. This is really important when we're displaying site-wide searches. There are tools in Drupal, such as Views, which people are starting to explore to build their search pages on, but that's not really geared towards heterogeneous content.
When you have a mix of contents, then it's really important that you're able to display that effectively inside your search page. Whereas views, it gets really, really tricky to say, "Okay, for this content type, display it this way. For this content type or this schema, display it another way."
That's the first thing that the Rich Snippets module will give us, is a nice display. Now we'll talk about how to actually say, okay, this is a date, this is the start date, that sort of thing.
There is a module called schema.org. It's just schemaorg, one word. It's a very simple module that doesn't require a lot of configuration, but you effectively download it, install it, and it allows you to effectively tag your fields and your content with the type of schema that denotes what that content actually is.
If you download and install this module, what it does is pretty simple. If I go to my structure, go to my content types, edit my content type, it gives us this new vertical tab that says schema.org settings, and this allows us to actually specify what type of content this is.
If I said, okay, this is a blog, I could start typing, and it would give me the options that are available. All the options are on the schema.org website, and I'm not going to go over them in detail because there is a lot of them. Just to give you an idea of how much there are, you start off with your basic top level stuff like an event, organization, that sort of thing, and then inside of these have various properties that say, okay, for this event, this is the end date, these are the attendees, so a lot of structured information there.
Each one has a lot. Let's see if I can get the documentation here. Okay. That's not what I want to show. Full list. Again, this highlights why this is a great tool for this type of search results display because as we scroll down, this is the nested hierarchy of schema.org schema and properties, so you could see there is a ton of them. The module right now supports a subset of them but it's going to support more.
As we're building our content, it's really important that you use this module and explain what your fields are. When I actually create a field, if I click Edit and I scroll down to the edit settings, you see here that I also have schema.org mapping so I can say the property. I could say this is the start date. Then what the Rich Snippets module will do is based on your schema and properties, it will display your content differently.
Because this is start date, if I go back to my DrupalCon settings, then it knows to display the actual start date up here because based on this result being an event, it's probably what people are going to be interested in, so it gives them some context about the content that's being returned so that they can see what's going on without necessarily having to click on the piece of content itself.
I'm going to stop there and take a couple of questions for two minutes, and then we're going to move on to statistics and then stop for general questions.
Speaker 1: Okay. We have two questions. Can the custom Solr search results page be used in panels? This might be from the last section.
Chris Pliakas: Yes, I believe it can be. The reason why I say that is because the Acquia Commons distribution is making heavy use of panels and is using Apache Solr for its search engine. I say with confidence that yes, it can be used with panels.
Speaker 1: There is one more. Where is the extension to add to Apache Solr autocomplete which allows for statistics to be involved and not just keywords?
Chris Pliakas: That's one thing that's not available just yet, but it's on the road map for the statistics module that we're going to display next. This is one of those items where I wanted to make people aware of the different trends that are emerging. This is one case where it hasn't been implemented yet, but it's going to be implemented. As you start to look forward in your search solutions the next three, six months, look for this as an option.
Speaker 1: We have one more question. Why do we need Acquia Search when everything seems doable from Drupal Search?
Chris Pliakas: Yes, and that's a great question. The first thing is that Drupal Search won't scale. The Drupal is built on relational database technology, and relational databases simply won't scale for full text searching. They're really geared towards saying, okay, find me all blogs or find me all users, that sort of thing. But when you start to enter keywords into the mix, it will take your entire site down pretty quickly because it will bog your stuff down.
Regarding Acquia Search, you can run Solr locally, and we've contributed a lot of these add-ons back to the community. However, the value add that Acquia provides right now is that we have Solr configured in a highly available cluster, so there is a master/slave replication so that if one server goes down that end users can continue to search. We also integrate the tools that allow for file attachment indexing. We also have a security mechanism that we've applied on top of Solr.
Solr actually doesn't have security out of the box, so you can actually do a Google search and find a lot of Solr instances that are unprotected. You could delete that index. You could add content to that index. We've added a security on top of Solr that allows you to connect securely and make sure that you and only you have access to your server. Also, we manage it 24x7.
One of the things I do want to talk about going down as we talk about statistics and contextual computing, there are things that we're experimenting with Acquia Search that will adjust relevancy based on user actions. This will be a set of tools that integrate with Drupal and integrate with various tools that will provide more relevant results to your users beyond just keywords. There is going to be a lot of value and a lot of focus on contextual computing with Acquia Search that's really going to differentiate it from not only core search but from using Solr locally.
Speaker 1: There's a few more, but we can get to them at the end.
Chris Pliakas: Yes, sure. What I'm going to do is just wrap up really quickly with the statistics. There is one point that I want to hit home, and I'll try to stop by 1:55 to save some time for some questions afterwards.
There is an Apache Solr Statistics module. Let me clear out some of these tabs here. I think that's it. Or maybe it's Apache Solr Stats. It's probably Apache Solr Stats. There we go.
There is an Apache Solr Statistics module that you can download, it works for Drupal 6 and Drupal 7, that gives you some information in terms of how many requests there are, what type of things people are searching for, but it's more geared towards site administrators, not necessarily search page builders. The reason why I say that is because if I go to my search and I search DrupalCon, it's going to count that as DrupalCon, the keyword being searched.
If I click on events, since the page reloaded and it actually queried Solr again, that statistics module is going to say, okay, DrupalCon was searched again. What this really does is it says show me content where people have to click around to find what they are looking for. It's not necessarily indicative of what people are actually looking for on the site.
One of the branches that's being worked on, it's actually a sandbox project right now that will be merged into, back into the Apache Solr Statistics module by Q1 of next year … I can't find it here … there is a sandbox that's an Apache Solr Statistics fork that's used to experiment with this stuff. That's what I'm going to be showing you today. The important thing is that it's more geared towards the search page builders, and it also tracks what people do after they search for something. It allows you to track what we call click-throughs.
If somebody searches for DrupalCon, we can see what pieces of content people are actually selecting, so we can make informed decisions about how to configure our search and how to modify the relevancy.
What I'm going to do is click on modules, search toolkit, and enable Apache Solr Statistics. When I click on Apache Solr Search, now I have a new tab that says statistics.
What I want to do is I want to enable the query log. This captures stuff about what searches are being executed. Also, I want to enable something called the Event Log. In order to enable this, you have to copy a file from the module to your Drupal Group so that it can capture the information as users are clicking on it.
We're also going to capture user data. By default, that's off, but you can capture data not only what people are searching for but who is searching for it. Based on your privacy policy, you can enable or disable that setting.
There is also what I'm about to explain, the law of retention policy and backend, by default, logged to the database, but for busier sites, again, there is going to be the availability to send that to different sources.
I'm going to say a configuration, and I'm going to execute another search. If I search for DrupalCon and now click on DrupalCon Portland, if I go to Reports, Apache Solr Index, Statistics, this gives me some interesting things. It gives me the top keywords, so it shows me what the top keywords are that people are actually searching for. Equally as important, top keywords with no results, so you can see what people are searching for and not getting any results for.
If people don't find the content they're looking for, they're going to leave your site, so this is a really important metric. Also top keywords with no click-throughs, so if people are searching for things and they're getting results but they're not clicking on anything, then there is probably going to be some modifications to make sure that they're getting displayed the correct results.
Here, we see the top keywords. We also have click-through reports. If I click on that, it will show me the pieces of content that people are selecting in the count. As you start to gain some more traffic on your site, this will give you some transparency in terms of what people are doing on your search page, and more importantly, what they're doing after.
As we talked about the contextual computing, it's really important that you monitor what people are looking for, and this is a great way to do it. Again, it's what people are looking for in your site and what they are selecting, what they find relevant. The search page is a great tool to help you modify your experience and tailor it to your users.
We have a couple of slides to end up, but that's really what I wanted to highlight, is that contextual computing is more the trend, that there are some tools that you can employ now that are going to be improved upon in the future to make sure that Drupal is the best solution available in search to serve relevant content to your users. Search is really becoming a big data problem, and search is also becoming a solution to that problem.
Big data is capturing a lot of information and then making sense of it, doing something with it. As your sites begin to amass a lot of data, search is a great tool to help your users sift through that data and find the relevant content that they're looking for, and that's really where the trend of computing is going over the next five years, so definitely pay attention to search as a tool to help make sure your site is keeping up with the latest trends and desires of your end users as they look for engaging experiences.
I went over but we'll take some more questions.
Speaker 1: Okay, great. Would you recommend using these modules on a Drupal 6 site using domain access?
Chris Pliakas: Domain access is a little bit tricky especially with search. Some of these things are … let's take a step back. The way a domain access works is that it builds upon the Drupal node access system, so that adds some challenges in terms of search. Not only does a search solution have to be domain-access-aware, but everything around your site has to be domain-access-aware.
Theoretically, you can use your Drupal 6 site with domain access. It's just that it gets a little bit tricky because your index is logically separated as opposed to physically separated, so there always is the chance of your content either lagging behind in terms of getting that access information or accidentally getting exposed to other sites when it shouldn't be, so it can be done, but there has to be a lot of thought and a lot of careful planning to make sure that it's implemented properly.
Speaker 1: The next question is does the schema.org also expose the extra info to search engine spiders?
Chris Pliakas: Yes, it does. That's actually what the module is geared towards. It's geared towards the external use case, and it works, it provides that metadata that Google will pick up the images and the additional metadata. But what the Rich Snippets module does is it takes that information and uses it inwards. By default, it actually is geared more outwards, but the work that's being done right now is taking that and also apply it to your site search, so it's a win-win.
Speaker 1: The next question is what if the non-Drupal contents are dynamic pages, how do you import those contexts? If not, is there a federated search solution?
Chris Pliakas: I think it's important to first say a federated search solution might not be exactly what's being asked for. When we think offederated search solution, we think of things like Kayak or other engines that actually query out different data sources and compile them together.
There are tools in Drupal that allow you to query different sources simultaneously. However, that's probably not what you're looking for. You're probably looking for a unified search solution that displays results instantly.
In order to do that, you can leverage tools such as crawlers, such as Nutch, which will integrate with Solr. The key is again getting that data into a format that Drupal can recognize. But the trick is using those tools to crawl or expose your external data to get them into Drupal.
There are also ways that you can programmatically connect a third party data store and index that into Drupal using the APIs. But again, it's more of a developer task and something that has to be coded.
But with Acquia Search, definitely look for an offering sooner rather than later to index external content and bring it into your Acquia Search Index.
Speaker 1: All right. We'll take one more. How can you make information more important based on the statistics? What ways to set this up are available?
Chris Pliakas: Can you repeat that question one more time? Sorry.
Speaker 1: How can you make information more important based on the statistics? What ways to set this up are available?
Chris Pliakas: Sure. I'll give one example from Acquia.com. We have an offering called Dev Desktop, which is a local stack installer for Drupal. A long time ago, it used to be called DAMP, Drupal, Apache, MySQL, that sort of thing. What we actually have noticed is that based on our statistics, people still search for DAMP more than they do Dev Desktop. We noticed that trend, and the way that we modified our search results was to take advantage of some of the things that Apache Solr has, and when people search for DAMP, we add a synonym to Dev Desktop so that when they search for DAMP, they're actually getting the content that's relevant to Dev Desktop, which is what the products mean now.
This is what Google does. This is why Google results are very relevant. They have hundreds of full-time engineers analyzing their search and doing things like saying, "Okay. If you search for a FedEx tracking number, we're going to show you the FedEx webpage." Now it's automated, but that was used by analyzing the statistics, and those are the types of techniques that you can employ on your site based on what your users are actually looking to do.
Speaker 1: Okay, great. I think we're going to have to end it here. Thank you, Chris, for the great presentation, and thank you everyone for participating and asking all these wonderful questions. Again, the slides and recording of the webinar will be posted to the Acquia.com website in the next 48 hours. Thank you.
Jess Iandiorio: With that we will get to today's content. Again, I'm Jess Iandiorio and I do product marketing for both Acquia Network and Acquia Cloud. I'd like to introduce Dan Kubrick, who is my co-presenter. Dan, if you could say hi?
Dan Kubrick: Hi, everybody. Thanks for joining us.
Jess Iandiorio: Great. I'm going to go through a little bit of information upfront about the Acquia Network, for those of you who aren't aware, and then I'll turn it over to Dan, who's going to do the bulk of the presentation, as well as a great demonstration for you.
For those of you who received the invitation through us, you probably heard the heads up, that Trace View has joined the Acquia Network. We're really excited about it. Those of you who don't know what the Acquia Network is, it's Acquia's subscription service, where you can obtain support tools to help your Drupal site perform better, as well as access to our extensive knowledge library.
The library, we like to think of it, has the answers you need to all of your burning Drupal questions. There are about 800 articles, a thousand Frequently Asked Questions, a really extensive library of podcasts, webinars and videos. We do have a couple of partnerships with drupalize.me through Lullabots, as well as Build a Module for other training resources that you can get access to.
In terms of our support team, we have a 24/7 Safety Net and our support offering follows the sun, so wherever you're located, you'll have a local resource that can respond to your request. We also perform remote administration, which means for customers, we can go in and make Drupal module updates for you, as well as security patches. We have about 60 people across the world on our Drupal support team, so the best concentration of really high quality Drupal talent you can find, if you do happen to have Drupal supp
ort needs. We encourage you to learn more about that on our Web site.
The last area that Acquia Network provides is all the tools, and we refer to it as the Acquia Network Marketplace. Some of the tools we built ourselves, like Acquia Insight. If you're not familiar, it's about 130 tests we run proactively against your Drupal code and configuration to tell you how your site's performing across security, overall performance, as well as Drupal best practice implementation. It's a really great tool that customers use, probably on a daily basis, to get them a to-do list to figure out how they can enhance their site.
SEO Grader is a very similar tool that we built with our partner Volacci, and it has the same UI as Insight. You get a score, you get proactive alerts for tests that have tasked and failed, recommendations for fixing. It's just looking at different criteria than Insight does. It's looking at the things that help improve your site's search engine optimization.
Acquia Search is our hosted version of Lucene Solr. That's the webinar that we have next week. If you want to learn more about that, please feel free to sign up. On the right-hand side, we get to third-party tools that our great partners provide to the Acquia Network customer base. I mentioned drupalize.me and Build a Module already, and those are tools that are helping you learn more about Drupal.
When it comes to optimizing your site, we have a variety of other partnerships with Blitz and Blaze Meter for load testing, Yottaa for site speed optimization and Trace View and New Relic for looking at your application, and actually taking you through the stack and figuring out other areas for performance enhancement, and that's what you're going to hear about today from Trace View.
Lastly, we have partnerships that help you extend the value of your site. Oftentimes, these are most valuable to a marketing audience, but it could be to someone technical as well. Mollom, for instance, is spam blocking. The technical person would implement it, but at the end of the day, the marketing person typically cares about spam and how it could harm your site and your brand.
Visual Website Optimizer is A/B testing when you want to figure out whether one, promotion or call to action on your Web site performs better than another. Chartbeat is real-time analytics, trying to figure out where are your site visitors coming from and what are they engaging with on your site. Really great, easy-to-use tool, similar to Google Analytics, a little bit more of a focus on social activity and where people come and what their social behavior is.
Lingotek is translation/localization services, so you can work with Lingotek to bring your site into a new geography, localize the content and they have a variety of different ways that you can work with them. You can have a machine translate, you can tap into an extensive community of people who can help with translation or you can actually have a moderator that you can hire through Lingotek, to watch all of the translation process and ensure its success.
That's a really quick overview of the Acquia Network. I'll be on the webinar the whole time, monitoring Q&A and able to take questions at the end, but at this point I would love to turn it over to Dan for the remainder of the presentation. Dan …
Dan Kubrick: … that introduction, Jess. Again, I'm Dan Kubrick, one of the co-founders of Trace View, and what we provide is a SaaS-based performance management solution for Web applications. It's part of being included in Acquia Network. We're actually providing a free 60-day trial of our best day plan. You can sign up with no credit card required and try it out, but I'm going to talk a little bit more about what we actually do and show you a quick demo, and then you can see if you want to sign up after that. Without further ado … can you see my screen all right, Jess? Great.
Thanks again for tuning in. What is Trace View? As I just mentioned, we provide a SaaS-delivered performance insight service for PHP-based Web applications. We also support Ruby, Python and Java, but we're really excited to work with the Acquia Network, and one of the reasons that they selected us to come onboard is because of our particularly strong Drupal insights.
That comes from a combination of our work, as well as community support in the form of a Drupal module that provides very deep insights. I'll get into that in a minute. The types of users that really enjoy and take advantage of Trace View are developers, people in Ops for Web applications, support and also engineering management.
The goal of Trace View is to provide low overhead performance management and insights for production environments. What this means is, you have a Web application, I'm sure you've run into problems, as I have in the past, where there's something that either due to production load, production hardware or production datasets, it's very different performance-wise, in terms of throwing errors or whatever from development, and because users are really perceiving the performance of your production Web application, you need to be monitoring that all the time.
Trace View provides a very low overhead solution for providing extremely deep insights continuously in real time for your application. Our secret sauce that differentiates a little bit from other APM solutions is what we call full-stack application tracing. Basically, what this means, I'll dig into it in a second, is that we're watching the request from the moment it leaves your user's browser as it goes through the Web server, the application layer, out to the database and caches and ultimately return to HTML that then gets rendered and parsed in the user's browser. This provides the true end-user experience, as well as great diagnostic detail to get into what's actually going on in your application.
Finally, we take this data and put it into a slice-and-dice interface that's really designed to provide the most actionable and clear insights for your performance data, and that means going beyond averages into very precise distributions, helping finding outliers, slow queries and ultimately, down to the line of code within request.
How does this all work? Let's take a look at full stack application tracing for a minute. What we're going to be getting in the browser is the network latency for communication between the browser and your Web servers, the time it takes to process the DOM, the elements in the HTML is returned, and finally to fully render the page and all of the things that go on with it, up until it's document-ready.
On the server side of this, be that virtual or physical hardware, we can start looking at the request, starting at the load balancer or the Web server to see, are the requests getting queued up before they hit the application backend?
What's our app layer performance like? What end points in the code are particular hotspots? Are we throwing exceptions, if so, from where? How are we using the database? What queries are being run? Are they taking a long time? Cache performance, how many cache requests are we making per page load? What's our hit rate? Finally, down to the actual hardware underlying all of it, what's the I/O latency like? Do we have excessive CPU utilization or are we barely touching the cores at all? Taking all these data and providing not only visualizations and insights, but also proactive alerts based on it.
To make this a little bit more concrete, let's look at an example of a Web application you might be familiar with. This is a simple LAMP stack, Apache, PHP and MySQL and I've also added in memcached and an external API, maybe you're using Mollom, maybe it's your payment gateway, whatever else. As a request comes into this system, it makes requests down to the different components of your application, calling out to memcache. Perhaps it's a cache miss, so you go to the database and pull back some results out to the API and ultimately, you return HTML to a user.
After installing just a couple of debs or RPMs, which is the form of installation for Trace View, or actually a single click if you're hosted by Acquia, we can put instrumentation at various points throughout your application, requiring no code modification, that reports data back to us in the cloud in real time. The cool thing about our instrumentation is how lightweight it is. A tunable fraction of request coming into the top level of your stack is selected for tracing.
At each point that's interesting. We fire off a UBP packet non-blocking to a daemon running on local host. This daemon does the work of forwarding over a secure channel to us, and what this means is that throughout the request path of the request your application is serving, there's actually no blocking calls, and so there's no chance for the request to get held up. Additionally, the overhead is completely configurable. In production environments for our customers, we see one percent or less overhead from this tracing that's, at the same time, providing very deep application insights.
The final thing I should mention here is that our insight isn't really limited to the interactions between components and your stack. Though we can start observing the browser and proceed through the load balancer and so on, there's actually a great deal of Drupal internal insight that we're able to provide, and this is largely thanks to a custom Drupal module that's available on drupal.org. What you're going to get from that is being able to break down your performance by menu item.
For instance, if you have many URLs that really map to the same underlying code path, you might want to look at particular URLs or you might want to look at that code path within your application. Being able to filter on menu item is pretty interesting. I'll show all these in a minute.
The second interesting piece of functionality is the ability to partition your performance data by the type of user. Oftentimes, the same code path will exhibit different characteristics for authenticated versus anonymous users, depending on how many customizations there are on the page. There may be administrative pages that are slower or you don't care about the performance of, and the module also picks up worked on by Drush, and so it's nice to be able to filter out all of those populations separately in terms of performance data, so you can optimize what you really care about.
In terms of the Drupal internals, there's two interesting things. The first one is time spent in Drupal hooks. You can see in hooking nits and watchdog and so on, really how your time is being spent throughout the stack as well as viewing individual node loads during the processing of requests. This module is very cool, and probably the best way to explain what's really going on here is to dive into a quick demo.
What we're looking at right now is the performance overview for several different environments in one of our customers who's been generous enough to share their data with us today. The company is All Players and they do product for groups to track and engage in common activities. We're going to dive into the staging environment here and look at the data for the past 24 hours.
What we're looking at is the performance of average requests, broken down by time spent in each layer of the stack over the past 24 hours. We can see that, on average, we're spending a fair amount of time processing requesting PHPs as well as in the database through these two separate interfaces. Additionally, Apaches, our Web server and Nginx lowdowns are on top. Courtesy of the Drupal module, we're also getting insight into the time spent in various different Drupal internals and we'll dive into this a little bit more in a minute. We can see that on average, it looks like PHPs MySQL calls are contributing a lot to the latency of our application here.
In addition to just figuring out the time that's spent on each layer of the stack felt, Trace View is also pulling out interesting features of the requests themselves. For instance, the domain and URLs are being requested. The menu items and the menu item parameters that are being requested, so they go pass through the application. Cache performance, in this case, because of the staging environment, we can see that our hit ratio is not very good. The traffic partitions that I was just mentioning, as well as the queries and RPT calls that may be expensive to make in your app.
Now, all of these tables are filters for our data, so if you wanted to see the performance of a particular endpoint here, in this case, it looks like our rest API, we can select that and we've now filtered the data, so we're only looking at the performance here. We can see that for this particular click path, it looks like there's a lot of query latency on average and in fact, here's the top two queries that are usually coming out of here. It's almost exclusively accessed by authenticated users as well.
Now, here's all these data coming from? We've been looking at aggregate data, but I mentioned our unique data source the trace, so I'm going to switch over to the second tab here, which is like a view source, if you will, for the data we are just looking at and now we can see a list of traces. Traces are snapshots of individual requests in full detail as they go through your application.
Let's take a look at a trace. For this particular trace, we're looking at a request to this URL. We can see the time spent on average, or the time spent by this request, in each layer of our stack, and we can also see this utilization up here, which is the flow of control of the request through the application. I'm just going to zoom in a little bit here, because there's a lot going on in this particular request.
The first thing that happens is the request enters Nginx which is our low balance here, and we can see that we've gathered some information about how the HTTP request came in and how it was proxied through to Apache, which is the second tier of stack here and finally into PHP underneath it. PHP starts to queue the Drupal bootstraps, so the first thing that happens here is we're looking something up in memcache. We could see where it's coming from in the application code, and a number of small queries start to fire.
As you proceed through this request, we can see, for instance, details about the different queries being executed, where they're coming from within the code, how long each one took. This one only took one and a half milliseconds, and what exactly the code was trying to do.
Here's the [boot hook 00:18:05], and so what we're seeing is overall, this is taking about 85 milliseconds, and as part of it doing a number of sub-actions including hook a net here, which then triggers this query and so on. With the individual trait details here, you can drill down on what's going on, what sequence did the events happen for a particular request, what was the slow thing that really bugged it down. There's some really interesting details down in here.
One of the cool things in PHP, that even though we instrument some other languages, you can't get is the sandbox notion of memory usage. We can actually see throughout a request here, we can see the memory use at the beginning and at the end of this particular query, the peak memory at any point in the request and so on, and this could be really useful for debugging problems where you're hitting a memory limit for individual request. There's a lot of great detail down here in individual traces, but let's actually go back up a level and come back and look at our aggregates.
In addition to being able to drill down on endpoints, they were interested in optimizing, we might also want to be able to view the data in a more précised manner. We're looking at our averages here. I'm going to switch over to a different view of this exact same data which we probably keep mapped. I'm going to overlay the average on it again here.
What we're looking at is like a scatter plot on the X axis, we still have time on the Y axis latency. The density of color in each root square indicates how many request had a particular latency at a certain time over the past 24 hours. We can see that while this red line indicating our average trapped this middle path, there's actually really two distinct bands in the data here. There's some faster ones, there's some slower ones. The heat mass interactive, so I'm going to grab a little patch of these outliers from the second band and see what's going on exactly.
These are actually all requests for the same endpoint, then some resource here as a view stage made by anonymous users. It's not surprising that they're clustered like this. This is pretty interesting because a lot of times when you have numerous endpoints with distinct performance characteristics, an average really just blends them together. Similarly, we've got the request volume on this bar underneath, and you can see that there's a large request volume around this time of the day. They're actually requests for relatively fast pages to load which brought our average down. You can still see that it wasn't that our application got faster overall, it was just that the distribution of requests that were made changed.
We can think about optimizing in a different way when we see that there's this constant population of relatively slow requests here that are spending from 6 to 10 seconds on the server side. Heat map is a powerful tool for drilling down on these types of performance problems.
In addition to providing the interface for slicing-and-dicing this data and filtering down to what you're really interested in optimizing, we also provide alerting based on this, so you don't have to be watching your application 24 hours a day. It's pretty easy to set up alerts. They're based on latency, on the performance of different hosts in your application, or on the error rate. You can actually filter each of this down to particular layers of the stack you're interested in, or even URLs or menu items.
For instance, it turns out that latency is actually a pretty good predictive alert, but maybe your latency for the application overall is kind of noisy and so instead, you decide to restrict to particular URL like your checkout page, and then you can get alerted if pages that are important to you start to perform outside of your standards.
The last thing I'll mention on the server side is our host monitoring capabilities. Latency and the behavior of applications are obviously very important, but sometimes what's really underlying it, i.e. the hardware, is the long point attempt is something that you need to keep an eye on. We're also gathering machine data in real-time without the performance of different hosts in your stack.
You can see there's a view here where we can look at all the different machines that we're monitoring, but actually, sometimes it's useful to be able to correlate that performance data with the application's performance itself. We can overlay the host metrics on our performance data here, so what I'm doing is we're looking at the past date again, I'm pulling up the CPU utilization on our frontend node, and we can see that as our request volume spiked yesterday afternoon, so did our CPU usage.
The other thing that you can get out of Trace View is end-user monitoring. You may already be doing this with something like Webpage Test or even with Chrome Inspector, but it's useful to be able to get not only the point of view of your test sessions, but of real users around the internet.
I'm switching over to a different customer kind here that runs some high traffic logs. We can see that they've actually done a pretty good job of optimizing the server site performance here at the average request taking about a quarter-second on the server site, yet the full page load is actually close to 11 seconds on average.
Let's drill down on the end-user performance data. We can see that on average, we're spending a lot of time in down processing, so getting together all the elements of the page and also in doing the page render so getting the document ready. There's a little blip here of network latency, but other than that, it's behaving pretty well there.
In addition to getting a latency here again, we're also associating it with the features of request. That includes geographically where the requests are being made from, the files are being used, the URLs requested, and the code path is within the application. If we wanted to figure out what our performance is like in the United States or maybe in British Columbia, we can filter down to data from this region.
We can see the URL is being requested and which ones are performing well or poorly as well as the browser is being used. We can get comparative browser usage and finally associate all of these down again to individual requests and individual browser sessions so that we can get into that performance data in a highly granular way.
That's Trace View in a nutshell. I'd like to hand it back over to Jess and open it up for questions.
Jess Iandiorio: Thanks, Dan. Sorry, we're on mute here. That was a great demo. We really appreciate it. The first question we have is, are you related to Stanley Kubrick?
Dan Kubrick: No, but thank you for asking.
Jess Iandiorio: Sure. We have one question. Would you mind reading it, and I can't see them. Do you support Drupal six and seven?
Dan Kubrick: Yes. We support Drupal six and seven, and the community module does as well.
Jess Iandiorio: Okay. That person also asked about eight, but that's not available yet, but I assume once that's available next year, you guys will be supporting that as well.
Dan Kubrick: Definitely.
Jess Iandiorio: Do you support Linux distributions?
Dan Kubrick: Yes. Currently, we provide debs and RPMs for Red Hat's CentOS to Debbie Anne and Amazon Linux-based environments. I should also mention, if I didn't earlier, that it's a one-click install for Acquia's hosted members of the network.
I see there's another question about the setup in general. After you register for a free trial, you actually get walked through the install process within the application. It's basically just installing three components from most users: a package that has our base, a package that installs Web server instrumentation, say an Apache module, and a package that installs a PHP extension.
After that, as you install each component, you'll get immediate visual feedback within the application which will prompt you to continue, then in the future, because we're providing packages, it's actually very easy to use, either Puppet or Chef to work this into your automated deploy.
Jess Iandiorio: All right. We've got about 10 questions in the queue here so hopefully we can get through all of these. The next is, do you support cached versus non-cached, CDN versus non-CDN analytics, can they break it out down at that granularity?
Dan Kubrick: We currently don't have visibility into requests that are going to the CDN except for to the extent that they speed up your end-user performance. Getting more statistics on full-page caching behaviors is something that we're interested in the future.
Jess Iandiorio: We have two questions on the difference between Trace View and New Relic. Could you speak to that at a high level?
Dan Kubrick: Sure. We get asked about this pretty frequently and there's basically three main differences. The first one is our full-stack application tracing. The same technology that allows us to follow requests starting in Nginx or Apache or Lighty also allows us to cross the wire for subsequent RPC calls if we're using backend services, maybe with restful APIs. We can actually piggyback the unique identifier across those, so you can associate the work being done in your frontend and backend services as well, which is pretty cool.
The second thing is our data analysis and visualization, in terms of the granularity of the individual request view, particularly those three-point internals as well as the analysis that you can do with the heat map, is pretty unique compared to New Relic.
The last thing is actually our pricing model. Instead of pricing per host, Trace View is priced per trace, and the number of traces that you send us is configurable via your sample rate. What this means is that you don't have to worry about buying a number of licenses to cover your entire deployments or having auto scaled nodes not be covered by your application performance instrumentation. You can actually set it up and use consumption based pricing.
We offer plans that start at just $95 a month, but there's a two-month free trial, so you can definitely get your feet wet without having to worry about it. A lot of people find that our pricing model can be interesting for their environment because of the lack of purpose pricing.
Jess Iandiorio: Great. Just for the folks on the phone who might not be Acquia Network customers, can they do a trial directly through you guys if they're not an Acquia Network customer?
Dan Kubrick: Yes. Unfortunately, it's not nearly as lengthy, but you can head to appneta.com/starttracing, or just go to appneta.com and follow the links to sign up for a free trial.
Jess Iandiorio: Okay. Does Trace View work with an environment where Varnish is used?
Dan Kubrick: Trace View does work with Varnish, but we don't provide any Varnish specific insights.
Jess Iandiorio: Okay. We got a question on mobile. How can this be used to monitor the performance in tablet and other mobile devices?
Dan Kubrick: As far as applications on mobile devices, those should be monitored from the perspective of the API calls that they're making to say a restful back end service, or actual browser page views on mobile devices that's completely covered by our real-user monitoring instrumentation, and you'll find that just looking at the real-user monitoring data we gather there's some very long page that's from mobile devices, which is pretty cool to be able to do to separate out there. Our instrumentation works on all mobile devices, but mobile applications are viewed from a server-side perspective.
Jess Iandiorio: Okay. Where is the performance data stored and how much storage do you need to store it? Any metrics that you can provide or …
Dan Kubrick: We actually take care of all the storage at a SaaS-based service, so you don't have to worry about any storage or scaling the storage on your side maintaining our upgrades. What you do as a Trace View user is install the instrumentation that gathers the data and we'll take care of the rest.
Jess Iandiorio: Great. This question is lengthy, asking about more information, do you collect pops or Sourcepoint breakdowns? What Geo has the slowest response time? I know you showed some Geo stats earlier.
Dan Kubrick: In terms of geography, what we're basically doing is using the IP to look up the origin of the request. In terms of actual network conditions on the point between your servers and the end-user, Trace View doesn't provide insights instead network connectivity, but AppNeta has other SaaS-delivered solutions that actually provide a great deal of insights into network performance, even from just a single side of the connection.
If you're interested in that, feel free to shoot me an email afterwards to inquire or head to appneta.com. Trace View will tell you the latency and the fraction of it spent the network, but not a great detail about hop to hop performance.
Jess Iandiorio: Okay. Are there any HTTPS implications or loss of fidelity or metrics or details?
Dan Kubrick: No. We're not putting any proxies in between. HTTPS works fine with Trace View.
Jess Iandiorio: Okay. You may have already answered this one. Is there a specific node under the lowdown's identification, instrumentation, HTTP or MySQL daemons?
Dan Kubrick: Sorry. Can you repeat that question?
Jess Iandiorio: It's there a specific node under LD's identification or instrumentation, HTTP or MySQL daemons?
Dan Kubrick: I'm not sure I clearly understand the question, but in order to get installed, we actually observe many of the components from the application layer itself, and we live inside the Web server as far instrumentation goes, and the application layer so you don't have to worry about modifying your database servers or anything else, if that's what the question was.
Jess Iandiorio: Okay. If that person is not …
Dan Kubrick: If you'd ask that one again?
Jess Iandiorio: Okay, so there's some clarity. Let's say there are five nodes under a node balancer wherein one node performs different than the others, can Trace View help identify the outlying node?
Dan Kubrick: Yes, because we're gathering metrics on a purpose basis, especially if that's showing up in terms of that node is thrashing or using more CPU, that's something that you can identify using Trace View.
Jess Iandiorio: Okay. You're doing a great job. We only have two more questions left on this first batch, so if anybody else has questions, please feel free to submit them now. The last two. First is, does this also monitor Solr search server performance?
Dan Kubrick: We watch connections mid Solr and view the performance there, and we also have Java instrumentation that can look into Solr's internals to some degree, mostly CPU and load-wise, but a little bit inside job as well.
Jess Iandiorio: Okay. Are there any issues installing this on Amazon, classical balance servers with EC2 instances and RGS database?
Dan Kubrick: No. We have tons of customers running in EC2. The only caveat is, if you're using RDS, you can't actually install our system agent on that RDS machine, and so we'll just be observing the queries and query latency for RDS.
Jess Iandiorio: Okay. What about Windows and IIS support?
Dan Kubrick: Windows is on the roadmap for 2013, but today we only support Linux-based environments.
Jess Iandiorio: Okay. Does Trace View also track affiliate program performance codes on third-party sites?
Dan Kubrick: Not out of the box. You can add custom instrumentation that will allow you to track the metrics that you're interested in for your application, but that's not one of the things that we have automatic instrumentation for.
Jess Iandiorio: Okay. Someone heard Apache being mentioned a couple of times. Is Nginx supported as well?
Dan Kubrick: Yes. We provided a module for Nginx, as well as a number of package versions of Nginx that contain the module, so yes.
Jess Iandiorio: Okay. Great. We have a question about can we use New Relic and Trace View at the same time? I'll answer from the Acquia Network customer perspective and then Dan may have something else to add. If you are an Acquia Network customer, and you're currently using New Relic, you cannot run New Relic and Trace View at the same time.
You would need for us to turn off your New Relic agents in order to enable the Trace View ones, and then we would need to turn the New Relic ones back on for you after the Trace View trial, if that was your preference or you could move forward just with Trace View. That's for Acquia Network customers right now, and I don't know if that's different for you, Dan, for other people who might want to work directly with you guys that aren't Acquia Network customers.
Dan Kubrick: We can't control what you do, but we don't recommend it. Both of the New Relic extension and Trace View hook in to PHP's internals, and so we can't always be on top of the releases that New Relic is putting out, and they're not always keeping in stuff with us, and so we don't advise customers to go down both rods at the same time. What we do have, especially during evaluations is often some customer will try New Relic on one or two machines and Trace View on one or two machines as well. That's the ride I'd go.
Jess Iandiorio: Okay. Great. Well, that's actually all of the questions we have. Nice work. That was a lightning round of questions. It's really nice to see people engaged and asking lots of questions as someone who does two or three of these per week sometimes. We really appreciate all of the interest and attention and questions.
If anybody has any last questions, I'm just going to flip to the last slide here. It's just contact information, if you'd like to get in touch with either Acquia or New Relic or Trace View. Any other questions? We'll just hang out a couple of minutes here. Let's see here. Is there a raw data extraction life cycle?
Dan Kubrick: Currently, we provide an API for exporting some of the data in the interface, namely the slowest queries, the slowest URLs, the slowest code path to the application. We don't have a full read at API, but some of it is extractable.
Jess Iandiorio: Great. All right. Well, that was very productive. Everybody has 15 minutes back in their day. Thank you so much, Dan. Really appreciate your presentation, great overview and lots of good answers to the questions. You can get in touch with AppNeta and that's the company that owns Trace View, if that wasn't clear. It used Tracelytics, now the company name is Trace View and it's owned by AppNeta, just to clarify that. You can get in touch there or you can get in touch with Acquia. Please feel free to send us any more questions you might have on Trace View and/or the Acquia Network.
Dan Kubrick: Great. Thanks so much, Jess, and thanks, everybody.
Speaker 1: With that, I am going to turn it over to Barry. We had about 30 minutes of content for you. So again, please ask questions along the way, and thanks for joining.
Speaker 2: Okay, thank you, Tess. Today I'm talking about continuous integration with Drupal, and what that means and how you get there. Creating really good websites, as anyone who has ever tried to do so, is hard. You have to do a lot of thought of user design and talk to your customers and figure out what you want and do the visual design and implement it. It's a lot of work, and that's what many of us do for a living.
Then you have to deploy it and get it up running on a site, on a server somewhere. Really, that shouldn't be hard. That's not ultimately the creative part. That's not the business that most of us are in. The fact is, that it is kind of hard. We all know that getting your site up and scaled and running and deployed efficiently is kind of a pain in the neck, and there's just no way to reduce any of that pain, right? Well, that's sort of what we're going to talk about.
There is a process, a development methodology, called continuous integration, that has become fairly popular along with the agile movement over the last maybe 10 years or so, that makes the process of developing most kinds of software, but particularly websites and dynamic products that can be changed very rapidly, unlike if you put software on a CD in a box and ship it, there's a limit to how quickly you can iterate, but when you're putting something up on a website you can iterate very, very quickly. Continuous integration is a process that really takes advantage of that.
Continuous integration has a number of principles. By working in very small batches, you're able to make small changes, deploy them fairly quickly. You always know when you're doing a deployment that you're changing only a little bit of work that you did just yesterday or maybe the day before, so you haven't forgotten what it was instead of work you did six weeks ago and you have no idea what the changes are going to be. By releasing very frequently, only work that you did yesterday or the day before, you're never really surprised that oh my God, this thing that I did two weeks ago doesn't work with the thing that I did four weeks ago, and now I'm kind of screwed.
Then as part of a continuous integration process, part of the methodology is to constantly test everything, so that when you do a deploy, you've already done that deploy 15 times before and you know it's going to work. There are a number of basic principles of continuous integration, as I said. There are not principles that I or Acquia or the drupal project made up. These are, as I said, widespread within the software development industry. I have a link here to the Wikipedia article on continuous integration where I basically took these things, and we're just going to sort of talk through them and describe what they mean and how it affects building sites with drupal and how you can take advantage of it.
I just managed to skip ahead many slides. Using a source code repository, this is sort of the minimum steps, step zero, for doing good software development. Most people that I've talked to within the drupal community are doing this, many are using GET, SVN, Exist. There are other systems that exist, I'm not going to talk about which one you should be using or why. Frankly, they all work. If you need one or the other, you'll probably know it.
But you absolutely must be doing all of your development in a source code repository so that all of your developers, whether there's one or multiple developers, are always committing their changes on a very regular basis, ideally every day, to a development branch. Then having that development branch automatically integrated with a testing environment so that as soon as the code is committed, each increment is a little step and pushed up to your main code repository, it gets deployed in a development environment that is a clone of your production environment, and then your tests get run on it. Every commit, every test is being run. You know immediately if something broke.
Making all versions easily accessible means that at any time, let's say a test does break. You did some development, you commit the code, you run it in your test environment, and it blows up, and you're like okay, what happened, what did I change, I don't think my code broke it, maybe it did. You need an easy way to get back to any previous version that you had so that you can compare, did this really work before? Maybe it was broken before and my new change didn't cause it. You need a way to get back to every previous version that you've released in order to be able to tell.
An audit trail, affectionately known as a blame list, helps you not just in the source control sense of who made this commit, but who deployed this commit? Yesterday, I see that someone pushed the latest version from testing into production. Who was that? Because maybe they knew, if something is breaking, or maybe if something is fixed, they probably know why they pushed it. You need to know who to go talk to in order to go figure out what was done and why.
Automating site deployment. You have an audit trail, you know who is doing what, but it still needs to be the case that in order to push your site live, you need some kind of automated process so it's very quick and easy, right? The idea is you develop … you do a little bit of work in a small batch, you write a little change, you commit it, it gets tested, you push it into your testing environment, maybe your stakeholders or other people play with it, and then pushing that out to live needs to be a very easy process. If it's a big chore to push out or release the production, then this whole process of trying to make small aggregated changes falls apart.
Measuring the results. Okay, so you pushed changes out. You're making all these changes all the time. You need to know, are they really helping? Of course, helping depends on what you made the change for. Maybe it was a performance enhancement, in which case you need a way to measure is my site faster or is it now slower? Did my performance enhancement backfire on me? If it's a usability improvement, are users able to use the new feature or make a conversion to a sale or whatever improvement you're going for. Are you able to … you have to be able to measure the small change that you made and deployed rapidly is having the effects you want, because if it's not, then you're very quickly able to go back and iterate again and make another small change and test it and deploy it using a very effortless work flow.
This whole … all of these principles combined make it possible to iterate very rapidly. That all sounds great, right? Okay, terrific, I'll just go turn that on and we'll be all set. Well, how do you get there? How do you integrate this process into developing of a website?
Well, there is, roughly speaking, two choices. One is you can build it yourself. I'm going to take a few minutes to talk about what's involved with building it yourself. There are a lot of people who have written a lot of different blog posts and articles and given presentations that drupal con-end every other technical conference out there, explaining how to do this. Many of those presentations are excellent and there's a lot of good information out there, and there are companies that do build this themselves and it's a perfectly reasonable thing to do if you wish to invest the time in it if you have a really good reason. Let's talk about what's involved.
The first thing, of course, the first principle is you have a version control system. Well, that means you've got to host your version control system somewhere. You need a GIF server or an FCN server or whatever other version control system you want. Maybe you could host your code at Get Hub. Okay, or there are hosted FCN services as well. Set up that account, start using that service, and now you have to integrate with that service.
The most common way, now that you've got all your code managed somewhere, the most common tool for building this yourself that people use is call Jenkins. It was formerly called Hudson. Jenkins is a fabulous tool. We use it internally, and what you end up doing is you write a lot of little jobs, a bunch of custom shell strips that do things for you. For example, I just made a commitment to my repository. I would like to deploy that into my development environment. Well, I can make a Jenkins job that listens for any commit on my version control, and then does a check-out, and maybe runs R-sync or some other copying tool to push that into my web server. Of course, if you're running on multiple web servers, then you have to write your Jenkins job to know about that, push it to multiple servers. You have to decide do you do each of your web servers one at a time, in which case you have a problem because you're deploying your code first to one server and then to the next and then to the next, and so maybe you'll have a version skew for awhile, or you can try to write your script so that it copies it into a temporary area on each web server and then it simultaneously is possible, maybe throws a SIM link from one old directory to a new directory. Maybe you want to get really clever and try to do all those copies in parallel. As you can see, that script which starts out oh, I'll just copy my code when I make a commit, it can get a little complicated and involved.
Anyway, now you've written that script. You've got your code deployed. Well, it's frequently the case when you're developing a site that you want to use a copy of the production database on your testing environment or your development environment. You want the latest data to test the latest user contributed whatever, to test your most recent changes on. You can write another Jenkins job. When you run this job, it will go connect to your production database server and copy that database into your test environment or to your development environment.
Frequently, when you do that, you want to operate on the database in some way by sanitizing it. Maybe you want to remove all of your customer e-mail addresses so that you don't, in case of some bug, God forbid, you don't spam all of your customers from your dev environment. Or maybe, this is the problem that I used to run into a lot, you have FSL turned on on your production site. Maybe for the whole site, maybe just for your user log-in pages or some other subset, and you copy your database into your development environment, and you go to try to log-in to your dev site and it redirects you to the FSL version and maybe you don't have an FSL certificate on your development site, so now you've got to go manually turn off the module, it's a pain in the neck. It's another kind of scrubbing or sanitation process you want to perform on your database as you copy it from production back to staging.
So you write a script for that. Now, as I said, you want to test, when you deploy your code, either when you deploy it to your testing environment, maybe there are some tests you want to run when you deploy to your production environment. If you have your script that deploys codes on commit that you wrote a couple bullets ago on this talk, you add to it to say run drush simple test or run load test or some other process. Another script.
Now finally, your test has passed. You'd like to push your code into production. As I said, one of the principles is you need to be able to access all prior versions that you've released publicly so that you can always get back to every version you've released for testing or verification so when it's time to push to production after your tests have passed in staging, you need to make some kind of symbolic tag in your version control system that says this is a version that I released today, and then push it out to your prod environment. You write a little script that uses the get tag command or the SDN tag command or whatever. The point is, you end up writing a lot of these little … they all seem simple in principle, and for the most part none of them are that complicated on their own. There's just a lot of little steps that you end up having to do.
Before actually you can even do all of those scripts, of course you have to have a server close to run Jenkins on and to run your website on, and maybe you need multiple servers because you don't want to be doing all of this deployment and testing and all that on your production box, so you've got production web servers and you've got your testing web servers, and unless you're going to be running your … you probably don't want your Jenkins service running on your development and test web servers because then your development and test web servers are not an exact clone of your production web servers, so when you push your code from development to production, you can't be really sure it's going to work because the server is not exactly the same. Therefore, you don't want Jenkins installed on your development machine. You want it on yet a third server. Now you've got at least three machines to manage, assuming each of your … assuming your site is only running on one server.
Very quickly, you're managing several different boxes. You need some way to build those servers, configure them, and it has to be an automated process. If you have a set-up where all right, when I need some new package on my web server, some PHP extension or whatever you might want, if you just log-in to the box's route and install it, then when that server blows up, which it will, you're not going to know how to rebuild your service, how to rebuild your server, so you have to automate the management of those servers.
You can do that. There are great tools out there to do that. There are tools called Chef and Puppet and CF Engine and lots of things you can go read about. You have to set all that up. Obviously, if you're running a service, you have to manage security updates, bug fixes, stuff like that.
Then of course, when we were talking about the Jenkins jobs, and I was saying somewhat lively, oh, I need to copy it from the dev environment to my test environment. Well, you have to have a dev environment and a test environment. That means you've got, if you're using Apache or Engine X, some other web server, you have to create multiple virtual hosts, one for each environment.
You have to configure the domain names and the FSL certificates and the PHP INI for each of those environments. Maybe they're the same. Frequently, they're subtly different. Maybe in your development environment, you want PHP to have the debug extension or the XP bug or XH prof extension installed, but you don't want that in production. You have to manage a different PHP INI file or a different set of configs. Frequently, you'll have FSL in production, but you won't have it in your dev and test environment. You almost certainly want different domain names for each of your environments because when you visit mysite.com, mysite.com is going to have a DNF entry for one particular IP address and you can't use that to access both your dev environment and your production environment, so you end up having configuration files you have to manage.
All right, well, you could edit those by hand and put them in a version control system as part of your server build. Again, not a hard thing to do, just another step. Multiple databases, right. Clearly, when you're running your development and test environments, you don't want them talking to your production database, because then they're going to screw all kinds of things up off of your live site. That means that you actually need three databases, one for dev, one for test, one for prod. Each of those databases will have at least a different name, if not a different user name and password, so you have to manage the settings, your drupal settings at PHP files, to talk to each one of those databases in the correct place. So your dev code, your dev site talks to your dev database, your prod site talks to your prod database.
Then of course, if you're not just running on one server, your site you want to have in a more scaleable or more high availability environment, you have to deal with all of that kind of configuration. Your database servers, if you set up dual master databases with fail over or if you want to use memcash or varnish or … each of these other tools, you have to configure those. You have to automate the configurations that you can get them back when they blow up. You have to be able to scale that service, so when the load on your database or on your solar server or whatever increases, you're going to have to know how to scale that up.
This is not a talk about telling you how to do these things. As you can see, there's a lot of stuff you have to do, it's just to give you an idea of what all these things are. Oh, by the way, I haven't yet talked about you need to build a back-up and restore all these things. You have monitor them 24 by 7 because by now, as you can see, you've got a lot of different pieces moving all the time, running your site. Any one of them can and will fail. Processes crash, servers crash, disks could blow up. You have to monitor it, and then of course you have to have someone to answer the monitoring. Get a page in the middle of the night and do something in response to it. Ultimately, you need Ibuprofen and beer and drugs to keep those people happy. It's a chore. You can do this. I mean, I'm describing it as a lot of work. It is a lot of work. There are companies that do this themselves and are very happy with it. But just understand that you're making a real investment in time and resources, so you have to have a really clear understanding of the reason that you're building it yourself.
Speaker 1: I just want to do … I want to interrupt you quickly, Barry, just to let everybody know that we're actually running some polling questions during the webinar, so if you haven't checked yet, we already asked one question, which is have you heard of continuous integration yourself. We had about 46 people respond. We're going to launch another question in just a minute that's going to ask if you've actually build a continuous integration functionality yourself. Thanks for your attention and participation there.
Speaker 2: Okay. Thanks. All right, so option one is build it yourself, of course, and as I said, you can do this. You really don't want to. Maybe there are some companies that have a really good reason and for them, of course, it's completely justified, but for the most part, this is not the business you're in. You're in the business of creating really killer websites, either for your own business or for your clients, and you're not in the business of doing all of it infrastructure management.
As Jeff said at the beginning of the talk, if you actually like doing this stuff, please let us know because we will hire you.
Option two is use someone else's system, and of course this is the part where I say we have a product that does all of this for you. Now I'm going to show you how it works. Just for my own little convenience, I'm going to have a cheat sheet where I pull back up the principles of continuous integration so that I can remember all the things I want to show.
For this, I am going to need to share my desktop, which I can do from here. Tess, can you confirm that my desktop is going through?
Speaker 1: Viewing your desktop.
Speaker 2: Okay. What I am looking at here is the main page of the Acquia Cloud area of the Acquia network, which is what I'm going to be talking about for the beginning today. The first principle of continuous integration … oh, this is interesting. I can't actually see my cheat sheet because I'm in desktop sharing mode, so I'm going to have to remember it.
Speaker 1: I'll write them up.
Speaker 2: Okay. It's user version control system. Acquia Cloud supports both GET and FCN. We show you every time you create a site on Acquia Cloud you get a repository, the URL is displayed right up here at the top. If you prefer one or the other, you can switch from one version control system to another. It's pretty easy to do. The way that Acquia Cloud manages this is that within either GET or FCN, you have what are called branches and tags. A branch is like the master branch or some feature branch, maybe you're developing some new provident feature and you create a branch called provident. Frequently, everyone just develops on the branch called master, and then within each of your environments, development, staging, and production, you can choose which branch you want to be deploying. In this case, I'm deploying the master branch in dev. What that means is any commits that you make to the master branch is within a few seconds deployed into your dev environment.
Similarly, you can choose … I'm sort of skipping ahead of myself, but when you do a release … if I say, for example, all right, I'd like to deploy the code from my dev environment into staging, you can just drag and drop your code from here and it gives you a little confirm box and says are you sure you want to do this? When you say yes, what it does is it creates a symbolic tag. In this case, based on the date, 2012, March 7th, pointing at the tip of the branch that you dragged. So if I drag the master branch to staging, I'm going to make a tag. Of course, you get the tip of the master branch, and then deploy that in the staging environment. Now I have, each time I do that, a copy or a symbolic reference into the exact code that I've deployed on a certain date and time, and now that's running in my stage environment. Then when I'm happy with this code I can deploy it over to my production environment, again with a drag and drop. That's step zero, using a version control repository.
Automate testing. There is a bunch of things you might want to automate, as I said. There is running your system test, or running your drupal simple test, or running a load test, or any kind of other action that you might want to automate when you perform a task like deploying your code from dev stage. The way Acquia Cloud manages that is with something called a cloud hook. A cloud hook is a script that you put into your code repository that Acquia Cloud runs for you at the right time. I'm going to switch to a shell here. In here, I have a directory called back route, and that's where my code lives. That's my drupal site. I also have a directory called hooks. Within the hooks directory, I have a subdirectory for each environment. In this particularly one, I've only put a hook in for the staging environment, which is also called test. Within the hooks test directory, I have another directory that says what action I want a hook to run on.
This says in my test environment, whenever I do a code deploy, when the action is complete, I would like to run all of the scripts that are within this directory. At the moment, I happen to have one of them, which is called update DB, and what this one actually does, this … sorry, this doesn't actually run tests, this runs … hold on … this actually runs the drupal update dot PHP functionality. It uses drush to do it. So here example is a hook script. It's given its command line arguments, in this case, the target environment, in this case test, because this hook script is installed in a test directory, and it very simple runs drush update DB. It uses this, which is a drush alias. Some of you may or may not be familiar with drush. Drush is a command line and scripting tool that lets you perform various operations on your drupal site. These aliases, so @eebdotson.test is an alias that refers to my drupal site by name so that I don't have to encode in my script what server it's on, what directory it's on, what usernames are run as, all that kind of stuff.
Simply by dropping this script into my hooks test post-code deploy directory, every time I do a code deploy, for example, dragging code from development to staging, then this script will run and drush update DB will run as well. If, for example, I do want to run my system test, then I can … I actually have a sample script for that. I think I know where it is. Sorry, I'm just going to reach into my development environment here, and see … drupal test, there we go. I have this sample script called drupal test, and I will install it into my hooks test post-code deploy. Great. Now let's just look at what that test does, that script does.
Again, this one turns out to be just another invocation of drush with a little bit more wrapped around it, so here we get the site in the environment, we say which test do you want to run. This is a sample, of course, so it's pretty verbose and commented.
Speaker 1: We have a quick question. Someone missed the first 25 minutes. Does continuous integration require hosting in the cloud?
Speaker 2: Continuous integration using Acquia Cloud requires using Acquia Cloud. The first 25 minutes talked about the things you could do to build continuous integration yourself if you don't want to use a service like Acquia Cloud or some other hosted service. What I would recommend you do is … we're repeating this webinar at 1:00 and you could come them.
Speaker 1: And can they do it on premise though? Could it be based out of a … does it have to be a cloud-hosting other website in general to do continuous integration?
Speaker 2: Let me get to this in the question section at the end. We'll come back to this question. This hook script does some set-up, it makes sure the simple test module is enabled, but then it all boils down to this line right here, where again it happens to use drush to run tests, then it exits with success or failure. To automate your test, to automate update DB, to automate, as you can see, a database scrub or sanitation, you can put these hook scripts into your repo and then they run. I've shown you so far code deploys, but similarly, if you want to copy your files from production back to staging or a database from production back to staging or dev, then a similar directory full of hook scripts can run that will do whatever actions you want them to.
For this little demo environment, I actually have an example where a few minutes ago, just before the webinar started, a couple minutes after, I did a deploy from development to production. Now remember, in this particular code base that I showed you, in my hooks directory I don't happen to have any production hooks, but what you can see is … so it says okay, I'm starting my deploy, I create a GET tag, I SSH into my servers and I do some stuff, then I deploy the code, then down here, we say … okay, so it's all deployed now, then it says starting hook, post-code deploy. Of course, there are no scripts in this repo for the production environment, so then immediately it's finished because there was nothing to do. But if there was anything to do, it would have run it there.
You might think wow, what a poor demo, he's got a failure right here on the page. What's going on with this is I'm just showing you how hooks can actually help you even when they fail. I set this demo up yesterday. I actually installed a distribution into dev and I deployed it to production. I deployed the code to staging, but I never installed the database on staging, so the site, on staging, if I visit it, it just gives you a white screen because there's no site there. When I tried to deploy my code from development to staging, what happened was all right, I created the tag, I deployed my code, I did all this stuff, and then I started my hook post-code deploy, and it tried to run drush update DB, except there's no database there, there's no drupal site there. The code is present, but without a database, drush update DB can't run, so drush update DB failed. What this is showing you is that when your hook script fails, here's all the output. Drush is saying I tried my best and I blew up, and so it exited with a status code, and that gets surfaced via a failure in the UI. You can see that your hook scripts succeeded or failed based on whether the tack is done or failed.
That covers automating testing and using a source control test in a … okay right. So testing in a clone of your production environment. Obviously, we maintain each of these environments, dev, stage and prod, they might be on the same server, they might be on different servers, they might …your production environment might be on 12 web nodes and 2 databases or whatever, but we maintain the configuration of these environments to be identical. They always have the same PHP config, you have options you can turn certain extensions in certain places, but the environments are all … they all have … if FSM peg is installed, it's everywhere. If ghost script or image magic or whatever, those things are always everywhere.
Making all versions easily accessible. I showed you you can very easily get back to any of the previous versions that you've deployed just by using the tags. You can see all the previous dates on which we've run a demo. Having an audit trail, well that's the task log. It shows you at exactly what date and time every action was taken on your site. At the moment, one thing it doesn't show you is who did it. We're going to be fixing that very soon. We're probably going to actually replace this task ID column, which customers don't really have that much use for the internal ID number, with just a column that says who, and shows you what the name of the user was that did the deploy. That will be coming very soon. But you can already see what was done and when.
Automating site deployment. I sort of showed you that already. You can deploy code quite easily by dragging and dropping. If there's any other actions that you need to take, for example, when every time you deploy if you want to clear your varnish cache or clear your drupal cache or, I know one of our customers, and I think he's even on the phone at the moment, they store their user uploaded files not in the local file system but they store them in F3. If on deployment you need to synchronize new files into your F3 repository or whatever it is you might need to do, you just write a short little one-line script for your custom need and when you deploy your code, which we handle for you, those extra tasks will run.
Measuring the results, I'm going to actually put off for just a moment and show you at the end.
There's one other thing, sort of you'll be the first to see this publicly. A little bit of an internal feature that's going to be released probably in beta next week, is that I've been showing you how to do this on the user interface. You can actually do all of this as well from a command line, and from an API. We have … actually, I don't know if I've set up this environment to do it. I have not set up this environment as part of the private data. But what I can show you is that there are commands for … well, for example, I'll just show … I actually renamed these yesterday.
There are drush commands to do all of these things as well. If you want to deploy code from one stage to another, you could run a command like drush on your site, on a testing environment, and I hit enter and that will do exactly the same thing that dragging my code from here to there will do. Similarly for files and for database and for a bunch of other things that work as a part of … as part of Acquia Cloud. As a quick little demo, as I said, this demo site is not yet set up, but if I do just my personal production site, I hope this won't blow-up, I haven't tried it yet today. Oh, there it is, okay. I just retrieved some information about my production site. It's running GET. Here's my repository. If I say I want to retrieve my production environment, I will say look, this is the tab I'm running. Again, this is the same information that you see on the UI, it's just in a text form.
Very briefly, about measuring the results. There are a variety of ways you can measure the results. One I talked about is performance testing. Another is so you can test both sort of the external performance of your site, you can run a load test, have lots of fake concurrent users hitting your site. You can also do internal measurements of how much time is my site spending on database queries and MPHP and talking to mem cache and the file system, and at the very beginning, remember I said we are looking here at the cloud area of the Acquia network. There's a lot more to the Acquia network than that. In particular, we offer a bunch of partner services that you have either free or reduced price access to. Generally, there's always a free level that comes with the Acquia network that is generally more than you get for free if you don't go to the Acquia network, that lets you do a lot of this performance measuring.
For example, we have a partnership with a company called Blitz-IO, where you can do a load test. You can have a little cloud hook script, one line script, that you drop into your hooks directory that every time you push code to testing, it runs a Blitz-IO load test and maybe 500 users simultaneously from around the world all hit your site. We have a partnership with New Relic, which is … let me see if … hold on a second … I'm going to go into … this is called winging the demo in real time. New Relic is an internal performance monitoring tool that runs on your site, and here I'm going to go look at a personal website. This is not a demo of New Relic, but very quickly, this shows you … you can see how much time you're spending in PHP and in your database, and talking to external web services, and you can say oh, here's my slow page, click on it, and they'll give you information about what all your database queries are, you see clearly selecting from the access log is 95 percent of the use of my slow page.
You can see from this what's causing your site to be slow, and a feature that actually, a really cool feature that they just released fairly recently is that New Relic now has an API where you can call them and say I just made a release, and they will simply draw a horizontal line on this graph that says you made a release right here, and then you can say … it's … the tag for this release is, the person who did it, you can assign additional data to be shown on this vertical bar. We will very shortly be coming out with little sample scripts to put in your hooks directory so that every time you do a release, a vertical bar shows up here on your New Relic graphs and you can come and look and say oh, I pushed a release on day x, and/or five minutes ago, and now I can go look at my New Relic graphs and see the performance approved or it got worse, and you immediately have feedback about the nature of the change that you made.
There are a few other services. There's AB testing, visual website optimizer lets you do AB testing where you can see if I moved my buy now button from the left side to the right side or whatever, does that affect user behavior? Again, you can start tests when you do new releases, see how the data … get the data very quickly. These services are not things Acquia has implemented, but they are things we've integrated from partners to let you do this very rapid iteration, like getting data tied to all of your releases.
That's a quick demo. Let me go back now to the slides. Now, very quickly, I want to just talk about what the actual … what I've shown you is the technology of the Acquia Cloud platform. There are two different ways we … two different products we have based on Acquia Cloud. One is called dev cloud, the other is manage cloud, and I want to talk about what the differences there are.
Acquia Dev Cloud is the technology I've just … is primarily the technology I've just shown. It is Acquia's continuous integration platform. It's a developer-focused offering. It's designed for people who are building sites, either for themselves or for clients. It provides all of the integration and automation and power tools that I've just been showing. It runs on … and drupal tune hosting. It's the best hosting platform that we know how to build.
Managed Cloud is the enterprise version of this same technology, and what's different about it is it has high availability, load balancing, you can have Managed Cloud, your site running, and U.S. East Coast and Europe and U.S. West Coast with automated failover, and we pair that with our enterprise level support contracts where 24 hours a day you can call us up. If it's Saturday night at 3:00 a.m. and your site went down because of a bug in your custom developed module, we will help you fix that. Our support people will respond and do whatever is necessary to get your site back up.
From a technology point of view, in terms of the continuous integration platform, what this webinar is actually about, they both have the same capabilities. They all have the automated testing and the deploy from code repos and the hooks and the API and all that stuff. Managed Cloud is about white glove service, very high performance, very high-end support, and high availability and regional failover and that sort of stuff. Cloud Product Marketing perform, might want to give a more professional description of what those two products are, but that's pretty much how I summarize it.
That's the content that I had, and now we can talk about questions.
Speaker 1: We also have a poll open right now where we're asking what do you use for a deploying code? We'd love for you guys to weigh-in there. But any other questions that you have right now, please submit them. We'll stay on the line for the next couple of minutes, and thank you for your time. Maybe we can address the question about can you have continuous integration …
Speaker 2: Require hosting in the Cloud. Sure. I don't know exactly what you mean by this question. There's a lot of different ways to interpret it. Continuous integration, as a development methodology, you don't need us at all. You don't need the Cloud, you could run it on boxes in your closet with your own development team. It's just a way of doing software development. I'm not sure if that's what you're asking me. Another thing you might be asking me is can we use Acquia Cloud's continuous integration support? What I've been showing you with the automated deployment and the cloud hooks and the API, if you're not hosting on our platform. The answer is yes, sort of, and the way that we have come up with doing that is that when … let's suppose, for example, you want to do your development and your staging on our platform, but you want to deploy your production site in your own data center. If you're a company that has an existing data center and an IT staff, and for whatever reason you want to keep using that, your code is going to live in our version control system, your databases … your development and staging environments can be on Acquia Cloud, but then you can write a post-code deploy script for a code that says if I drag my code from staging to production, Acquia will deploy it to what we think your production site is, which is to say on our platform, but then your post-code deploy hook script can then copy that code off via FSH or R-sync or whatever you want, to whatever server or environment you have in your own data center wherever it is.
Similarly, if you go in the UI and drag your production database back to staging, we will copy what we think your production database is, but then your hook script can say all right, actually, I'm going to forget what was just copied from Acquia's concept of production. I'm going to go do an FSH my sequel dump or whatever, against my real production environment in my data center, and suck that data down and install it into the development environment. We actually do have customers who are doing this. They really like the user interface, the dev and staging environment, and the automation that we provide, but they need their own production data center, and so they're using hook scripts to integrate with their own off-site … or their own on-site off-cloud environment.
Again, I'm still not sure if that's what you're asking, so if you need more information than that, why don't you just send me an e-mail at the address that's on the screen.
Speaker 1: A question about is there a gira plug-in for Jenkins?
Speaker 2: A gira plug-in for Jenkins? I believe that there is, but I'm not sure. What he's talking about … so gira is a ticket tracking system. We actually use it internally here at Acquia, for where you track all the features and bugs and all that that you want to add to your software, and gira integration with Jenkins would be hey, every time someone posts a new fix to an issue in gira, go fire off a task that maybe will go run my system test. I suspect that exists. I know that gira and its code review system, crucible, has a API, so if it doesn't exist you could write it. Again, that's just work you'd have to set up yourself.
Speaker 1: You've shown dev stage and prod environments. Is there an issue if this is extended to dev tests, UAT and prod? So four environments, he said.
Speaker 2: Our system is very capable of supporting that. In Managed Cloud, we have customers running a dozen or so environments. In dev cloud, we do not yet have a UI for creating additional environments. If we see a lot of demand for that, we can. Again, it's fully supported internally. Really, it's just a question of do we add a UI to let you add and remove environments. If that's something that you need, contact us and we will at least bump up the priority, because another person asked and/or get around to implementing it. Just a question of backlog.
Speaker 1: Great. That actually concludes the questions that we have coming in right now. Thank you everyone for your time. If you'd like to join us and learn a little bit more this afternoon, we're going to host another session at 1:00 p.m. Eastern. One more question before we go.
Speaker 2: Do cloud hooks fire when commits are made to a branch, the master branch? That is coming soon. At the moment, we have cloud hooks for when you deploy code, either changing the branch or copying a branch or a tag from one environment to another, but not yet on commit. But we will have that probably within the next couple weeks. Just lots of things to do. We haven't gotten to that one, but it is coming.
Another thing that is currently not … that we currently don't do is … so as you can see here, when I dragged … oh, you can't see, I'm not sharing my screen. I will share my screen very briefly so you can see what I'm talking about.
When I deployed my code from dev to prod, we created a task in the task list and here, I'll do it again right now. What we show is that we show a little spinner, code is being deployed to prod and in the task environment … so the task list, you can see this task it was waiting, now it started, it's going to be running, and when it finishes, when this task finishes … okay, it's done now. You now know that that code deploy is finished. We don't currently do the same for a commit, so if you make a commit to the master branch, we will deploy it within a few seconds, but nothing in the UI actually shows you we started and we're done. Along with the hooks on commit, we're going to be adding that into task environment so that you'll know exactly when your commit is done deploying. Tess was just trying to get my attention.
Speaker 1: Another question coming in here. This question is an easy one. Does using continuous integration count as three sites on the network?
Speaker 2: No. What they're asking about is when you have a subscription to the Acquia Cloud, you have a certain number of sites that you can create and we're going to be moving to a pricing model where you can have as many as you want, you just pay per site. But each environment doesn't count as its own site. A dev stage and prod environment is one site. Really, a site, to us, is a code base. You have a version control system, a repository, and within there is a doc group, and that's your site. However many databases you want to create, if you want to do drupal multi-site, go to town, we over here on the databases UI you can create more databases and you can assign more domain names and using drupal's multi-side feature you can run however many multi-sites you want. That's still all one site, because it's just one code repository, one code base.
Okay, did I stop … oh, here I thought I was pointing at the UI and you couldn't see me. But anyway, the answer still stands.
Speaker 1: Great. I think that looks like … all the questions come at the end. Are there options like code sniffer, crack code, running code tests in dev cloud?
Speaker 2: Are there options like … I'm not sure what code sniffer or crack code are. Running code tests, you absolutely can run tests or anything else that can be scripted via the cloud hook that I showed. If there is some tool that you want to run, some script you want to run or some third party service, you write a little cloud hook that invokes it when you deploy your code or when you copy a database or when you copy your files or whatever it is you want to do. If that doesn't answer your question, then send me an e-mail message.
Speaker 1: All right.
Speaker 2: Anything else?
Speaker 1: Going once, going twice. Let's see here. Nope, that's just some good feedback. People like your demo, Barry, good job.
Speaker 2: Terrific.
Speaker 1: Thanks so much for your time, and you will receive an e-mail with a recording in the next 48 hours. Thanks. Bye-bye.
Hannah: Hi, everyone. Thank you for joining the webinar today. Today's webinar Is It Time to Consider Using Open Source Web Content Management for Digital Experiences with Stephen Powers who is the vice president and research director at Forrester Research. Also, joining us is Anjali Yakkundi who is an analyst at Forrester Research, and to finish up the presentation who have John Carione is a senior director here at Acquia. We are very excited to have Stephen and Anjali speaking for us today and we hope you enjoy the presentation.
Stephen: Great, thank you. My name is Stephen Powers. I'm a vice president and principal research director with Forrester. I'm joined by my colleague, Anjali Yakkundi, who is an analyst with Forrester. Today, we're going to talk to you on our portion of the presentation about whether or not it's time to consider open source web content management for digital experience initiatives. Anjali and I have been working on some joint research with Acquia over the past few months researching organizations that are using open source web content management. This actually really has been a fun project for me. It's something I've always wanted to do in my six years at Forrester. I actually did a project about four years ago, a paper, on open source WCM. One of the challenges back then was that it was very different to find examples of large enterprises, enterprises with a billion dollars a year or more revenue who were using open source WCM as their primary WCM for customer face experiences. That's not to say that we couldn't find plenty of people using open source WCM, but often it is was for part of their websites or Internets or for purely informal websites, some of the easier use cases.
That's really changed over the past few years. As part of this study, we did find some great examples of organizations, large organizations, using open source as their primarily WCM. Those we did speak to within the course of this study were very careful to emphasize that there were some situational factors at play with their open source WCM success. The results of that is what we wanted to talk with you about today.
The agenda for our portion of today's presentation is a fairly straightforward one. Number one, we're going to talk a little bit about the state of the market. This has a been a rapidly changing market ever since I started here at Forrester six years ago, so it's always been fun to cover. Anjali and I are going to talk to you a little bit about some of the trends in the market to give you some context of what's going on overall. Next, we're going to talk specifically about some of the results of what we found during our study about organizations who are exploring open source web content management for digital experiences or DX as we have it abbreviated in the agenda slide. Next, we're going to talk about some specific things you should be thinking about in terms of evaluating open source WCM because there are some differences between that and proprietary WCM. We're going to talk about that and what we saw from our observations during this project. Then, we'll wrap up with some recommendations.
To start, basically, the WCM market returned to the wild, wild west. It is kind of a crazy time. Why? Organizations that we speak to as well as that we survey continued to have some problems with their existing web content management implementations. Only about 20% of those we surveyed really claimed to be very satisfied. Honestly, it's not that surprising for a number of reasons. Number one, the use cases are getting a lot more difficult, aren't they? They're looking to use WCM solutions to support increasingly complex initiatives that rapidly change. We're not just publishing informational websites right now. We're not just publishing Internets. We're publishing things like highly personalized websites that are also repurposed onto the mobile platform, and they may have a lot more rich media. They have may be connected to campaigns. The use cases are a lot more complex. Let's face it, complexity brings more risks for dissatisfaction. Also, as I mentioned, there's a lot more functionality that's in play. There're a lot of other technologies that go into digital experience. WCM is a big portion of it. Five years ago, when I started at Forrester, people were talking about web content management as part of web content manager and strategies. The difference now is when they ask us about web content management. It's really within the context of a customer experience or a digital experience strategy.
What does that mean? That means that people are interested in how WCM is going to work with other components of the DX ecosystem such as search, such as e-commerce, marketing enablement technologies, digital asset management, CRM, commerce, testing and optimization, analytics. The list goes on and on and on. The integration issues are also adding to the complexity. Then, finally, there're a lot of organizational issues. Those have been out there regardless of technology. There's always misalignment between different groups. There's that classic IT business/marketing conflict. Those are all adding to the complexity and frankly the dissatisfaction here. Definitely, a lot of factors going on, it is a wild west atmosphere right now.
Anjali: As Stephen said it, it is a complicated and it's an evolving space. In order to make a little bit of sense about this we, Stephen and I, along with Acquia we conducted an online survey of 160 WCM decision makers. We interviewed about seven of those to get even deeper insights and a little bit more qualitative data. This was really the cornerstone of our research. This is going to be the cornerstone of all of the data and the findings that we'll show you throughout the next 30 or 40 minutes.
A little bit about the survey. We surveyed organizations that were mostly medium to large sized businesses, all had about 1,000 or more employees. They came from a variety of different verticals, government, high tech, financial services, publishing, CPG, manufacturing, media and entertainment, a whole hosts of different verticals. What I found most interesting is these WCMs decision makers weren't just from IT. Certainly, many of them were from central or distributed IT groups. We had almost 15% from line of business or corporate or online marketing groups. I think that's definitely a trend that Stephen and I have seen as we do this research. WCM is going to be more of a joint decision between IT and marketing. We're seeing marketing and these corporate and online marketing groups take more and more of a seat at the table in making these technology decisions. They might not be the only making the decisions, but they're certainly taking a seat at the table.
Stephen: Anjali, that's a great point. I think that it's important to emphasize that this is going to be joint decision. When we talked to some of the larger enterprises, particularly with the ones who have had the most success, it is a joint decision. It's not one or the other. I think there are some myth perceptions in the industry that everything is swinging away from IT and marketing in the business will make all the decisions here. That maybe the case in certain instances, especially with smaller initiatives, but the fact of the matter is if you truly want to have this universal multichannel experience WCM has to be plugged in to all of those other technologies, some of which I mentioned earlier, that contribute to supporting the digital experiences. Honestly, you can only do that with pretty heavy support from your technologist within your organization. I do think it's going to be a joint decision. Frankly, within the context of this particular research, we found that to be true again. Those companies which had the most success really did take joint ownership of these projects.
What are some of the greater barriers here to WCM success in general? I think the ones that are most interesting here are probably the ones where we're in the 20% or above and people were allowed to select more than one response. Corporate politics and culture at 43%, and lack of a company-wide online strategy 33% those are pretty closely related. It's not unusual for us to talk with clients where they don't have any kind of online strategy still. It's still too much from the bottom up, still too much grass roots instead of top down, or they may have very much siloed digital experience initiative. Line of business number one may be trying to do one thing, line of business number two may be trying to do another thing, and line of business number three is trying to a third thing. There's not a lot of agreement over what should be the priority. When that happens you can understand it's very difficult to have successful technology when your customer experience needs aren't prioritized.
Poor budget and resource allocation. That's a huge problem here. I think that we can all agree that online experiences are getting more complex not less complex. With greater complexity comes, frankly, a greater need to devote resources to it. Sometimes we'll talk to clients and they're still thinking they're going to be able to get away with the same amount of resources that they had when they were publishing pure informational websites. That's a problem. As these experiences become hyper personalized and much more contextual, you do need some more resources to maintain that.
Next, difficulty integrating the product with other applications. We already spoke to this. WCM is an important part of the digital experience ecosystem, but it's just one part of it. It has to integrate with all of these other applications like search and commerce and testing and analytics and things like that. When you have difficulty integrating with a product with other applications that's going to contribute to your dissatisfaction and be a barrier to your success.
Limited flexibility of the product. This can a problem particularly with people who are on older WCM products and haven't updated them in a while. They're still feeling constrained by using out-of-the box functionality and they're not feeling that the products are as flexible as they need them to be. Finally, 21%, it's that old chestnut, lack of IT business alignment. I have to say, since I started this one, we solved some of the problems, the companies that we speak with they have solved some of those problems. It's still a problem in some cases.
Anjali: We also asked these same decision makers to rate their satisfaction. I think if you see the data that's a little bit of a mixed bag. Only 3% said they were very dissatisfied, 9% say they're somewhat dissatisfied, a fair amount say they're neutral, about one in five, and many are saying they are somewhat satisfied, and only one in five were very satisfied. I think, Stephen and I, when we talk we really see that very satisfied as what organizations should aspire to, the goal of what you want your WCM solution to be. We see only one in five have made that, actually believe that their solution is very satisfactory.
Another thing I find interesting about this data is when we cut this by the WCM decision makers who are from marketing or from the line of business versus WCM decision makers who are from IT, we see a big difference there. IT is much more likely to be satisfied by WCM solutions. I believe only 8% say they were very dissatisfied or somewhat dissatisfied. When we compare that to marketing or line of business decision makers, almost 30% say they were dissatisfied or very dissatisfied. There's a little bit of a gap in perception and gap in satisfaction As we see marketing becoming more involved with the WCM decision making, I think we'll see this satisfaction become a little bit more neutral or maybe even a little bit more satisfied.
I think it's also interesting we cut the same data by solution type. Which of these 160 decision makers were using open source, proprietary, or home grown solutions? I think this one's interesting. In a lot of places they're very similar, but when we look at proprietary they hit a lot of highs. They're very high in the somewhat satisfied, but there's a huge drop off in the very satisfied. Only 8% of WCM decision makers who have a proprietary solution said that they were very satisfied. It's a little different, though, when we look at open source. We see they are a little bit steadier. There's 37% who say they are somewhat satisfied and there's no drop off, about 37% also said that they were very satisfied. Home grown again is a little steady too.
Stephen: Great. Thanks, Anjali. I think we agree here that, number one, we have rapidly changing needs that need to be supported by WCM. Number two, there are a lot of issues contributing to WCM dissatisfaction that go beyond just plain technology. There're a lot of people process issues that are going on as well, governance issues. I think it's very interesting to see the fact that the open source respondants don't have the same type of lows that the proprietary respondants do. I think that's quite interesting. Then, finally, I think the other important point from that section is that there really is a need for integration. It's a much biggest ecosystem that we're dealing with than before.
Next, let's talk about some specific examples of why organizations are exploring open source web content management for digital experiences. That's what the DX stands for. Open source WCM is gaining traction as a viable enterprise option across verticals. This is something that even outside of this study we started to see a little bit. At Forrester, we talked to our clients, there's bit more interest over the past 12 months in open source, a little bit more serious interest I guess I'd say. There's a more serious interest in SAAS, another alternative delivery model, a SAAS WCM.
As I mentioned, five years ago it was difficult to find those larger organizations that had deployed open source web content management as their primary WCM solution. There were always plenty people who had deployed open source WCM, but they were supporting smaller microsites or smaller scale initiatives. For this particular research, pardon me, we spoke with several organizations, large scale organizations, that are using open source WCM for their customer experience. I think one of notable ones was a large supermarket chain here in North America. Another one was an international pharmaceutical company. Another one was an international electronics manufacturer. There were really fascinating examples here. The real question is what are these organizations with successful large scale WCMs what are they doing differently now? After speaking with those organizations we've boiled down the keys to their success to a couple of factors or a few factors. That's what we're going to speak to you about in this particular section.
Anjali: I think our data really proves the point that Stephen was just making, that here we asked what type of solution are you using for your primary web content management solutions. This is primary. We used to see open source WCM really being used as maybe a secondary solution or a microsite, as Stephen mentioned. Here in this question in our survey we asked what is your primary WCM solution. You can see about 27% say they're using open source, 28% say they're using home grown. I think this is a little bit of an anomaly. Like I mentioned earlier, we surveyed medium and larger sized businesses. I think many of the people who are using custom coded are home grown are much more of the medium sized businesses. The larger enterprises tend to go with proprietary or open source. You can see proprietary has about 45%. I think it's also interesting to think about because even those who didn't choose open source as their primary WCM, almost 60% did consider an open source solution. Even if they didn't choose it, open source still had a seat at the table. They're still under consideration. I think that's an important point. As we see open source gaining more and more traction in the WCM market we can see this interest increasing.
Ant point I find interesting about this slide is when we asked all of these respondants why are they choosing an open source solution, it was interesting because more open source users chose open source WCM for a web redesign or web replatform effort more so than the proprietary or custom coded users. They had some other important point. We can see that open source is really gaining some traction in the market.
Stephen: I think the interesting thing there, though, I want to reiterate, I also felt that the home grown solution bucket was a little bit larger than I would've expected and certainly larger than I've seen through our customer inquiries I would say part of it might also be explained that it's possible that some of those who are citing custom coded or home grown are using open source as a base. It's definitely an interesting slide.
In a lot of ways the whole open source debate it's kind of like Coke versus Pepsi. I'm probably dating myself, Anjali. I don't know if you remember those. How many people remember the Pepsi Challenge back in the 80's where they had people blind taste test the two colas. Frankly, if Coke versus Pepsi has always been one of those things were people are very religious and they're calcified in their opinions. I am a Coke person The Pepsi Challenge showed a lot of people who claimed to be Coke people, but yet when they were blindfolded and they tasted the cola they actually preferred Pepsi.
In some ways, the open source debate is a bit like that in that proponents of either choice are often hardwired to believe what they believe. They like what they like often for valid and defensible reasons. Some organizations gravitate towards open source WCM based on factors side like in a corporate culture, they kind of like that exploratory type of project. Some of them have budgetary limitations and they've been mandated to look at open source because with the belief that it perhaps is going to save them money. There're some organizations that simply have a greater comfort factor with open source due to previous experience with other open source applications such as operating systems as well as their familiarity with the community principles that underpin these solutions.
For other organizations, the opposite is true. They often lean towards proprietary solutions because they believe sometimes justified, sometimes not, that it's the best way to mitigate risk, that they believe that they code is tested. It's more secure. It's more off-the-shelf. They're not going to have to do as much customization. They're used to dealing with the vendors. Some of the organizations we speak to they've dealt with some of these larger vendors for years. There's a comfort level there and there it's more off-the shelf. Again, its' this whole idea of getting out of those calcified positions and really thinking about what the best product, what the best fit is, what the best product is for your particular needs. That's where we found more satisfaction.
Organizations are definitely expressing interest in open source WCM for digital experience as we found in the survey. We asked them some of these responses why did you consider an open source WCM solution. I think the answers here is really interesting. Sixty-nine percent chose it because they believed that there was a lower cost. I'm not necessarily saying that's true. In fact, when we did some of the qualitative interviews, our interviewees really encouraged people to look at more than just lower cost. I think we can probably all agree that there's often a lower upfront cost because you're not necessarily making a big license purchase. However, it's really important to look at total cost of ownership. You may have a lower upfront cost, but depending on what your cost of customize and implement you could end up with higher costs at the end. I'm not necessarily saying you will it all depends on what product you select and how well it's aligned with your needs. I think lower costs is one of those things that is more than just upfront license fees, and I encourage people who are thinking about this in terms of lower costs to really look at the bigger picture of total costs of ownership.
Another one here, easier to customize. That's something that we definitely heard through our qualitative interviews. A lot of the companies that we spoke to were very happy. They had needs where they had to do a lot more customization. They felt that their web presence was really one of their main differentiators and they weren't going to necessarily be satisfied with out-of-the box functionality from their WCM. They felt that they needed to customize in order to support some of the more differentiating functionality. People were definitely talking about that.
Reduced dependency on software vendors. What some of the respondees meant here was that they didn't necessarily want it to be dependent on the software vendor for new features, didn't want to be dependent on them for their release cycle, even bug fixes, and they were happy to do it themselves. Scalability of the solution. There were some of them who felt that they were going to have a better luck with scalability for their particular needs. Availability and viability of the developer community. That's a huge one. That's something we heard again and again in our interviews. One of the reasons why people chose open source WCM. Those were some of the interesting responses within why people were choosing the open source WCM solutions.
Organizations are definitely exploring. They've definitely had some success. What we did after this was we wanted to point out, we wanted to gain some insights from those we spoke to, those we interviewed on what they looked for, what helped them, what were the evaluation criteria they looked at that helped them have some open source WCM success.
Anjali: We started first by asking who didn't consider, who didn't buy open source what was the stumbling block, why didn't they choose or consider an open source WCM solution. We though this could help frame the rest of our presentation about we need to think about some of these stumbling blocks and how to think about the myths a realities of some of these concerns.
You can see at 55% many people, we heard this often throughout our interviews, that in the beginning security of the software was a concern with open source. We'll talk about a little later about some of the myths and realities and how organizations we've talked to who have had success have worked around that. Lack of ability for enterprise service and support. I think that's at 31%, it's the second most cited reason. That's another issue that we heard come up again and again because open source is different. You don't have the vendors you just call up. It's more about coming up with a comprehensive plan for service and support and how are you going to work with open source in that way. It's a little different that what many of you who have been using proprietary solutions. It might just be a little different than what you're used to. We'll talk a little bit about that later.
We have some other issues here like legal issues or inexperience with open source in general were stumbling blocks for some people. Lack of skilled resources. We'll talk about that too later, about how people are coming up with support plans and coming up with a plan to actually support their open source solution. Product immaturity at 16% is another one that some people were concerned about, and overall complexity and difficulty of adoption.
We'll start with security. What I thinks interesting is that was the number one cited stumbling block for people who didn't choose or consider an open source solution. When we actually talked and surveyed people who are using open source they didn't see to express that same sentiment. About 50% of organizations with open source actually said that open source had neither improved nor decreased their level of security. They said it was pretty much the same. One theme we heard over and over again as we actually did the qualitative interviews was that security concerns weren't that different from those they're faced when they're implementing previous proprietary solutions. I think that's an important point to consider. Security is going to be a problem or an issue no matter what type of solution you have. They might just have slightly different issues, but it's still always going to be a concern.
I think the main thing that when we talk to organizations who had success with open source is that they came up with a plan for their security. They had a plan for perhaps one of the large supermarket chains we spoke to had a third party hosting their solution. That eased their fears a little bit about going with an open source WCM solution. Others we talked to thought that the security patches that were being released more quickly by the vibrant developer community they felt like that mitigated a lot of their concerns. Other organizations we talked to had independent security audits because, let's face it, with an open source solution you have access to the entire code base. You don't necessarily have that with a proprietary solution where you only have access to some but more likely you don't have access of this any of this code base. They were able to mitigate their concerns by actually examining the code base and they felt that that mitigated a lot of their security concerns.
Stephen: The interesting thing there, Anjali, is that they didn't dismiss the security issue just out of hand. They actually dug in and did some homework and did some comparisons on open source versus proprietary. Actually, we're seeing this within SAAS as well. SAAS we always used to hear about I'm afraid about the security with SAAS, and people are now starting to think, "Why don't I at least dig in to the model and see how it compares, and then I'll make a more informed decision."
Some of the other points to consider here, level of functionality. I think that when you compare some of the open source products to some of the higher end proprietary products you are going to see a different level of functionality. You're not going to see that huge array of functionality with some of the really high end proprietary products who are, let's face it, are in a functionality war. I think the real thing you want to question is how much of that are you going to use? For example, the proprietary vendors are really starting to focus on marketing enablement type technologies that allow you to multichannel campaigns and run really contextual websites and have a lot of personalization and things like that. You're going to have to ask yourself are you going to use all that functionality if you're considering open source product versus a proprietary one? Frankly, you could even use this argument if you're comparing two different levels of proprietary products or two different levels of open source products. How are you really going to use? What you really want to do here is have somewhat of a five-year plan, one that's a little bit solidified in the coming year and one that may be a little bit more vague as time goes on. You need to really understand what you're really going to be using over that five-year period because five years is roughly the average lifespan of a WCM implementation.
If you are buying a product based on functionality that you say that's really cool functionality, but you really don't know when you're going to use it that could be a warning sign that you may not ever use it. I think this is one of the big problems with enterprise software all the time is you're buying functionality that you don't need. Another one of our interviewees, one of the pieces of functionality that we're looking at were the user interfaces, and they felt that the user interfaces of the high end proprietary product they were looking at that they were more polished than their open source counterparts. The open source was enough of a fit that they decided that it was worth having to do the extra configuration and customization of the open source UIs because of all the other benefits they were going to gain.
Integration, another huge point here. As I mentioned earlier, you're going to be integrating WCM with all kinds of other products. What you really want to do is figure out what types of integrations you need, come up with a reference architecture and figure out where those dependencies are. Then, understand where there is integration functionality that you can buy off the market through prepackaged connectors and where you're going to have to code by hand. That's going to inform you whether or not you should go with an open source or a closed source product. If you can't buy much of the integration off the shelf and you're going to have to do some pretty complex implementations, pardon me, that's an indication you may want to look closer at open source WCM.
Finally, then customization piece. That's something that we talked about. It ties very closely in with level of functionality. You may get a little bit lower level of functionality and you may have to do more customization. On the other hand, you may require a lot of customization no matter what. This is the media entertainment story. For years, media and entertainment has used open source more heavily than some of the other industries that's because they have some very specific use cases and they found open source was easier to customize than a proprietary product. You need to think about what level of customization you're going to have. If you're going to have to do a lot of customization no matter product you source, open source may be a better alternative for you.
Ultimately, integration is very important here. Just a little bit of data to emphasize that. We asked the respondees in the survey which of the following would you like to see included in the same stack as WCM. I think we all have seen some of the higher proprietary vendors are really building their digital experience and customer experience portfolios to not only include WCM but some of the adjacent technologies that we were talking about earlier. Ultimately, interesting result of this survey is that 35% said we're not interested in having a whole lot of technology bundled with our WCM. We prefer best of breed. Why do they say that? Because of the fact of the matter is none of the people that we talked to or that I talked to as clients can really afford to do a complete rip and replace and replace all of their digital experience technologies with technologies from a single vendor. The fact is they already own some of these technologies, so they want to be able to do integration and they want to be able to integrate WCM with CRM and search and email campaign software and social network and platforms and web or social analytics. This digital experience story is going to be an integration play for the short term. It's the short to medium term, frankly. When you think about it way it's not too surprising that a lot of our respondees wanted a best of breed approach.
Anjali: It think the last point to consider is resource availability. I touched on that earlier, Stephen has mentioned it too. Working with open source is different. If you're an organization who's used to working with proprietary vendors, somebody you can up in the middle of the night, it's not like that with open source. The organizations we've talked to who've had the most success with open source the first and foremost start it out with a plan of how they're going to support their open source WCM solution.
One of the biggest workarounds that we've seen with the organizations who have had success is using a third party for-profit business who's dedicated to providing open source support, whether it's for implementation, hosting, or troubleshooting. That's helped mitigate a lot of those concerns. That's something that we heard over and over from interviewees. They were nervous about open source because there's no enterprise support, but then the third party has helped them fill that gap and that's how they've worked around those issues.
Lot of our other interviewees and things we've heard through inquiry and other things have really been positive about open source support because of the vibrant community. Of course, this depends on which open source solution you provide. Some have more vibrant communities than others. If you have the right community you can use them for not us trouble shooting or Q&A, but you can also use them for their community authored modules. That might be a really great way to add functionality very easily onto your platform without having to do too much work. I think these are some of the ways we've seen organizations work around their concerns over enterprises level support.
Stephen: Great, and a very important I think. It's actually one of the most important ones of the factors that you should consider is that support issue. Let's wrap up with some recommendations, wrap up our portion of today's presentation.
Number one, definitely evaluate open source. I think it's gotten to the point in its maturity where it's worth looking at. I think one of the things you don't want to get into is that calcified mentality of, my gosh, we're not going to do open source. Frankly, the other way we are going to do open source. One of the interesting things that came out of this survey, one of the interesting observations that came out of the study was people said, "Don't just evaluate something because it's not open source." Evaluate the products and evaluate them on their own merits and based on things like functionality as well as support and resource availability and make your decision that way. It's must better than falling back into that religious mindset.
Number two, one of the really nice benefits of open source is that you can get it a community version of the product and that leaves you free to pilot it. You can actually pilot it and see who well it works. There's also organizations we've spoken to who have installed open source alongside proprietary and they decided to see how it would go that way and they gradually expanded their use of open source after they found some success.
Third, engage with the community for information and validation. Any product that you are evaluating you should be able to see how active the community is, how responsive are they, are they willing to answer your questions, are they contributing a lot of community authored code, are there interesting references, are there people who like your company who are using it? Definitely engage with the community. I think the vibrancy of the community is a huge factor that you should be taking into account when you evaluate open source.
Fourth, explore those open source options carefully like Anjali said, particularly if you're used to dealing with some of the commercial vendors. The support options is one of the big differences here, so you want to see that if you are planning to move away from the proprietary vendor support model you're going to want to be very sure in how you're going to replace that with some open source options.
Then finally, focus on more than just cost reduction. Open source is not necessarily free I think of the interviewees that we spoke with the ones who had the most success here looked at open source as more than just something that they could get for free. Of course, they looked at costs, but it was more within the scope of total cost of ownership rather than just that very narrow slice of upfront license fees. They looked at things like integration and maintenance costs and support and culture and some of the other factors that we spoke about today. If you keep those factors in mind rather than just very narrow slice of upfront costs, I think you're going to be at a much better position to evaluate whether or not open source WCM is the right choice to support your publicly facing and digital experiences. That concludes our portion of the presentation. Now I'm going to turn things over to John.
John: Appreciate it. Fun to work on this solution and work on the survey with you guys. With that, I'd like to take some time to highlight a few more interesting points from the survey that we collected from our side and also talk a bit about our announcement last week around OpenWEM and finish off with a couple of case studies.
You're probably wondering to yourself for those that chose to participate in the survey what were the list of platforms that we were talking about here. Here's the full list and what's interesting is that Drupal is highlighted in the top five and represents the majority of the respondants for those that offered this information up for open source. It's important to understand that although it's really talking about all the different technologies that are available from an open source perspective that Drupal came out on top and is in the top five of all platforms that are represented in the survey.
Other interesting statistic was the business drivers for new WCM solutions. Regardless of what you're using there the top five for the main drivers for using a new WCM solution were limited flexibility, total cost of ownership, poor and inadequate functionality and the ability to quickly innovate. We found that was interesting because when we talked to customers those are most often cited for the reason they switched to open source. I think some of the top challenges folks and business drivers for folks moving are also reasons that folks are looking at Drupal specifically.
We also took a look at engagement by the solution type mapping proprietary and open source. One interesting point we found here is there have been some perceptions in the market that open source platforms like Drupal aren't ready for the shift towards digital marketing. If you look at the data in the box below it's actually statistically significant that it's virtually no difference between folks that are using these platforms for interactive marketing on multichannels whether that's proprietary or open source.
Barriers to success by solution types. If we split data again between proprietary and open source. I wanted to highlight a point at the bottom there in the orange box around limited flexibility of the product. What are the greatest barriers to success? For limited flexibilities, we think there's extreme contrast there between the 30.6% around proprietary highlighting that versus only 9.3% for open source. Flexibility really leading the way with open source and Drupal.
A couple highlights around when we just took a look at the WCM decision makers who were using open source specifically with the majority being Drupal, we took a look at these how strongly you might agree with the following statements around open source. Ultimately, some of theses when we combined strongly agree and agree open source came on top for reduced dependency on software vendors at 77%, combined open source provided us more flexibility 73% combined, open source lowered our costs 70%, open source is easier to customized 70%, and open source scaled easily at 66% when you combined strong agree and agree. Then, a few others, open source made it easier to innovate quickly that came at 67% combined. Open sourced shortened our time to market 53% and viability of open source developer community was key to a successful implementation that was also at 53% combined. Some pretty strong statistics and a strong showing for those that chose open source platforms like Drupal.
I wanted to take another quick look at the state of the market, more specifically for the Drupal platform. We are seeing that inside many organizations the web is broken. There are lots of technologies out there that might be really strong in an Internet or an Extranet of if we're doing wikis or doing your main corp.com site or an e-commerce site or a microsite. At the end of the day, these end up being stoked by technologies that really create islands of excellence, if you will, and it really costs a lot more to develop and create the extra piece needed to develop across these silos. They're also disconnected from a reporting perspective if you think about a chief marketing officer that wants to know everything that's happening in their hub of interaction on the web.
Where Drupal really shines is taking all these different siloed islands of excellence and really delivering integrated unified customer experiences out to your B to B to customers across web content management, social, business software, and e-commerce. Drupal really is a unified platform for content community and commerce which ultimately we think results in part of the reason you saw that open source gets the highest marks for folks that rated it very satisfied.
It also goes along quite nicely with some of the research that come out from Forrester this year. This is one of their recent reports which talks about defining your digital experience architecture, the need to manage, engage, and measure all of your customer interactions. If you look at engage I wanted to highlight three areas, content targeting, social, and transactions, we believe map fairly closely to content, community and commerce. If you are setting up a digital experience architecture for success we agree with Forrester that those capabilities need to be inside of a single platform to maximize those customer experiences.
Last week, we made an announcement around a new approach we're calling OpenWEM. OpenWEM really is that ability to create these best of breed customer experiences with unlimited Internet freedom and flexibility across the full spectrum of the customer journey. As you can see here, we consider that customer journey from attracting and engaging folks on the web to associating and influencing them within communities, prospect to prospect, or prospect to company, and then the last mile of engagement in e-commerce being able to sell, retain, and resell to them online. Across these market segments Drupal is a unified platform for delivering that.
Again, some of the additional Forrester research from earlier this year that talks about the concept of the open web and the ties of the concepts of the open web to open source technologies. We fundamentally believe that to implement and take this OpenWEM approach that you really need to embrace the principles of the open web. Those are providing an open culture and community of thriving developers; Having open APIs to leading best of breed engagement tools so you can, as we saw in that statistic, offer up a best of breed solution; have accelerated innovation on the web that doesn't rely on proprietary models for development and really relies on that open culture of contributing problem solving and code back to the community so it gets to customers faster for these experiences. Then, we fundamentally believe in responsive design mobile approaches and best practices as a very agile way to create those mobile experiences. Drupal really embraces the open web concept.
Overall, from an OpenWEM perspective of content community commerce, we believe it does it offer infinite freedom and flexibility to create these digital experiences online. There's freedom to take your code, to take your content, and if you need to take it to another hosting provider if we're not getting done. There's no vendor lock in here with an open SAAS model. There is unmatched innovation to be able as new technology is brought to bear to be able to get that technology into your website as soon as you need it for content and campaigns. That's through those 20,000 Drupal developers that are continually evolving the Drupal platform in real time.
We talked about the unified platform across the full customer journey. We think Drupal's a great platform for best of breed experiences because it's has a data driven modular architecture and content model that allows you really to very easily plug and play these best of breed marketing tools and input and export data as needed as Stephen talked about. Acquia in particular has been building a very mature cloud infrastructure and cloud business model over the last five years. As you'll see, other proprietary vendors roll out B1 models this year and next year. We believe we're absolutely ahead of the game for delivering digital experiences in the cloud if that's your next route.
Then, everything we do is about simplifying digital experiences and simplification usually translates to a lower cost of ownership. We believe that developer community offers a better supply of highly skilled developers that are cheaper. When you think about the ability for them to ultimately develop across content, WCM, social, business software, and e-commerce on the same platform that that's going to create better experiences. It's also going to lower your total cost of ownership. This is where we think the Drupal platform really excels.
Ultimately, how is taking an OpenWEM approach different from proprietary approaches? Are you experiencing any of the symptoms such as limitations around road map or road map trade-offs by proprietary development teams? Do you issues around complex customizations even after you've already paid exorbitant license fees for the software? Do you have multiple platforms installed today for content community and commerce rather than building it on a unified platform? Do you consider your vendor lock in a problem from all-in-one solutions stacks that have control of that customer data and feel a bit trapped? Are you having issues around immature non-existent cloud business models or ongoing maintenance fees from perpetual license models that are your only option? Many of those issues if you are experiencing any of those issues this might be the platform and support model to consider.
Last week, in announcing the OpenWEM approaches and customer strategy we did talk about some tools and products that we launched in support of it. we have a new product called Acquia media cloud in the content or web content management market segment. That's a new SAAS offering to manage rich media assets within the Drupal platform to do things like asset tagging and optimized transcoding for video across endpoints, even digital rights management.
On the community side, we announced a new version of Drupal Commons. Drupal Commons 3.0, very new with new responsive design templates for mobile collaboration, advanced content recommendations so folks in the community can get interesting content to themselves fast, and improved moderator productivity so that moderators can outsource SPAM blocking and community involvement to folks that they trust from an access control perspective. We continue to go build out ecosystem, so we announced Digitari as a new digital agency partner for us as well as Badgeville integration for doing gamification and reward systems within Drupal.
We think Drupal's a great system for flexible agile marketing as well, like I talked about, the Pinterest example. In February, Pinterset hit 10 million unique users. As of March, folks believe that having Pinterest image pinning capabilities on their website was important for digital marketers, and by April 15 Drupal sites already went live with Pinterest integration, so that really is the definition of agile marketing on the web.
We also have integration with best of breed tools. Acquia is helping build out this ecosystem such that whether it's CRM, analytics, marketing automation, campaigns and social, and whatever's next, we're going to offer APIs and continuous integration points to the latest versions of these technologies so you can use that Drupal module platform to plug these technologies in, and then Drupal if very powerful to be able to get that content out to your campaigns, out to your microsites, and across all the channels at the top here.
We have a very mature cloud model, as I mentioned, we've been building over the last five years. It's based on Amazon web services. What I'm showing here is for developers there's a whole host of developer tools to be able to create instances, develop them, and then publish, so take instances from development to staging to production and back and forth quickly and easily. We also have the Acquia network to be add additional technology such as Acquia search or SPAM blocking technologies, multibarrier testing, real time analytics. We have partnered with a lot of technologies to be able to get that quickly and easily from the Acquia network in a centralized location.
A couple quick examples across content, community, and commerce. I have the first example around content, specifically. Florida Hospital, one of the largest hospital chains in America, they were able to create mobile content experiences using responsive design techniques. In this case, what's really interesting about their implementation was that they were able to allow their patients to understand exactly how far they were from a hospital or what the wait times were from their local hospital so they could pick the one that was most appropriate. They're doing a lot of advanced use cases in health care along mobile.
For community, we have Daimler which set up a customer community to be able them build out their customer requirements for a particular model of their compact car line. They set up polls and interactive forums for prospects, to talk to prospects, prospects to talk to engineers inside of the company and really understand from the consumer themselves really a big data problem rather than doing focus groups to understand from thousands what they were looking in the next vehicle, so being able to set up those customer communities online and Drupal as well.
Cartier is using Drupal and the Drupal commerce distribution specifically for that to create these rich commerce and tranformative shopping experiences that embed content rich media, images, to really help folks in the last mile help them decide exactly what product is right for them. It's a lot more engaging when you think about the high end customers that are shopping online for Cartier. It's helped them increase their conversation rates by being able to use the rick content in Drupal.
I want to finish up right before we get to a few questions. We have some upcoming customer case study webinars. I went through those pretty quick. Customers that are initiating an OpenWEM approach for delivering digital experiences on the web. November 6th we have the Grammys, How Drupal Acts as a Media Hub for the Grammy Awards. November 25th, Humana, Fortune 200 company, How Haman is Using Drupal to Drive Repeat Visitors with Personalized, Multi-Channel Campaigns. You can go sign up for those now at the link. I think both of those will be very in depth reviews of customers embarking on an OpenWEM strategy.
Certainly, please download the full research paper. We went through a lot of it, but quite honestly, we probably only went through 50% or less of the research that's in the paper that's available today and that paper is titled Is It Time To Consider Open Source WCM For Digital Experience. You can go ahead to a microsite we created called OpenWEM.com and download that paper for free today. Please do that.
With that, I would like to open it up to some questions. I will who those questions are addressed to here. We have a few that have come in. For Stephen and Anjali, I'll start off. This question says, "You mentioned some in person interviews around open source survey participants. Can you offer any specifics on the types of enterprise customers or verticals you spoke with and their specific reasons for choosing open source?"
Stephen: ... tended to be cite that reason. Traditionally, that's been media entertainment. I think I mentioned that in the context of the presentation. We saw it in other areas as well. The supermarket chain, retail, they had some really specific needs around their UIs. They had a globalization, localization issue where they were going to have global content at the corporate level, but they wanted the local branches to be able to create their own content but also not override all of the global content. They did some customized user interfaces to take care of that. They also had to, I believe, had to integrate with some print-on-demand solutions in order to print out circulars. That is the type of integration they did. I think one of the other companies we spoke with they were in a regulated industry. They had the need for some fairly highly customized workflows. That was the type of thing that they were looking at. For some, they said they had a mandate. They were supposed to explore open source, and others they felt that they hadn't gotten their money's worth out of older proprietary platforms and they wanted to explore other options where the costs were done a little bit differently. As I mentioned earlier, I think the ones who were happiest didn't necessarily choose open source or proprietary. They were open to both they just chose the best fit. They chose the product for the best fit.
John: Great. Another one came in. Cloud to planet models are growing in popularity for these types of solutions, but we didn't have a lot of data or questions that focused on mature cloud models. Do you see that as a factor in some of the enterprise decisions?
Stephen: Eighteen months ago, I would've said no. Around that time we did a survey, an internal survey, of WCM decision makers. Most of them, honestly, didn't care about cloud. They said we just want something that works. We're interested in supposing our customer experience needs. That's changed a bit over the last 18 months, John. Now people are starting to want to outsource some of this, but they're still, I think, more concerned with getting it right and they're also interested in the different flavors of the cloud, whether it's a public cloud, a multitenant model, or whether it's a private cloud. We're getting more questions about it, but I still don't think we've reached the level of maturity in WCM where they're ready to wholesale outsource it. I also think that a lot of the organizations that we speak to understand that even if they should get a cloud WCM, it's going to have to be integrated in with some of the enterprise applications that they have on prem.
John: Great. Here's one. If I'm in the RFP stage for WCM and only have the resource to evaluate a couple solutions, what are the top three questions should I be able to answer to short list enterprise scale open source?
Stephen: That's a good one. I'd say first of all it's a functionality question. It always is. Is it going to meet my long-term functionality needs? As I mentioned in the presentation, answer that question less as does it have enough functionality to meet my needs, but also if you look at it does it have too much functionality to meet my needs. Do we really need all of this functionality? You may very well, but this is typical for enterprise software. Let's face it, people tend to over buy functionality, so look at it from both angles. I'd say the second one for open source, we mentioned it in the presentation, it's community. What is the vibrancy of the community? You don't want to pick an open source product that the community isn't helpful or there's a smaller community and it's not very vibrant and nobody's creating community authored modules. Then, I'd say the final one is the support model. The support model is, let's face it, it's different from the typical support model when you're getting support directly from the software vendor. Those are the three things that you should be asking yourself when you evaluate proprietary versus open source.
John: Great. One final question. I've seen some perceptions in the marketplace that open source WCM can't scale. It's not performance. Developers are needed inhouse or extensive customization is required. Would you say these blanket statements are accurate based on your research?
Stephen: No, I don't think they are. This is the trouble with blanket statements. I don't think you can generalize and say proprietary is more scalable than open source or vice versa. I think you have to look at the product itself. There are some high end proprietary products which have proven scalability. There are other proprietary products which have catered more to SMBs and they don't have the necessarily proven scalability that their higher end counterparts have. It's the same thing with open source. We talked to some companies or some organizations that had had a lot of success with certain open solutions, and then there are other source solutions which have more of a track record at the SMB level, again, the same thing with customization. As I mentioned when I was answering the first question, I encourage people not evaluate open source or proprietary as whole but instead evaluate the individual products.
John: Excellent. We're a couple minutes over. I want to thank folks on the line for staying on and hope you enjoyed the presentation. Definitely, download the paper at OpenWEM.com. Also, I'd like to offer a special thanks to Forrester. It's been fun working on this project, Stephen and Anjali. I think there's some great work here and some great knowledge to be gained from the research and the reports. Thanks for joining us. With that, I'll turn it back over Hannah.
Hannah: Thank you everyone for attending and thank you Stephen and Anjali for the great presentation and participating with us.