Microsites: Choosing the Right Architecture for your Project

This article serves as a guide for choosing how to implement a microsite when you already have an existing Agility instance and website.

What is a Microsite?

The term microsite is used to describe a page or group of pages that are meant to function as a discrete entity within an existing website. A microsite could live within an existing website in a subpage, in a seperate sub domain, or a different domain altogether.

Sometimes these page(s) include the same header and footer as the rest of the site/main entity and sometimes they have their own. This can include, but not limited to blogs, ecommerce shopping and checkout, and other portals for specific personas or user interaction.

You could even consider this site (help.agilitycms.com), as a microsite of our core entity agilitycms.com. They have different functions, audiences, and have few dependencies on each other (aside from cross-domain links to one another and some syndicated content).

Choosing the Right Architecture

In Agility, you have several different ways to implement microsites - part of what we think makes Agility versatile. We take pride in giving you options so you can evaluate and understand the implications of each before you make your decision.

Existing Website vs New Website

The first place to start is to determine whether this microsite should be built in the same website or in a new website. For clarification, a new website means it would be hosted on another subdomain/domain and have a seperate code base. This is a problem that all website administrators face and is not specific to Agility.

 

---

 

Existing Website

Adding your microsite into your existing website is a tempting proposition since you can easily reuse page templates, and modules from the existing website out-of-the-box. You also already have the Agility instance and website setup, and have a hosting environment for it. You can get setup in little to no time. However, you will still need some custom development done to address the requirements of your microsite. You might not even end up re-using any page templates or modules.

The draw-back of this is that there is no separation of concerns between your website and your microsite. They become one in the same.

SEO Comes Easy

Having all of your properties under one domain (i.e. same website) will mean that you'll automatically get the SEO benefits from those pages without having to do any work between domains.

Increased Complexity

Adding additional functionality to your existing website will increase the complexity of your website. This means the test coverage for the website will also expand. Whenever development changes to your website are made, QA will need perform regression testing across the entire site. Even if a small change to the microsite is made, it could break other aspects of the site, the same thing is true for changes in the rest of the site, effecting your microsite. At a certain point, it may become unmanageable and could result introducing bugs in production.

Potential Performance Impacts

Having your microsite and website in the same application can also introduce additional stress on your web server. For example, if you have your marketing site and ecommerce site within the same website, a big black-friday deal could send massive amounts of traffic to your ecommerce microsite. If not handled well, your ecommerce site may have slower response times as a result. Consequently, it will also slow down your marketing site. Sometimes it doesn't even take a traffic spike, it could just be a new bug introduced by the microsite that is now negatively affecting the whole website.

Requirements

If you decide to implement your microsite within the exiting website, it must be hosted on the same domain(s), same web application, and the same web server.

---

New Website

Implementing your microsite as a separate website has many architectural advantages, while it can also be built in a way that your end users (visitors) never notice they've left the main website.

Having a separate website allows you to maintain a clear separation of concerns between your functional properties.

Easier to Support and Maintain

When you separate your entities into different websites, this means you have separate code bases. Any changes made to one entity will not affect the other. This allows for a more streamlined deployment process and only requires QA to regression test the application they are deploying. In theory, this should result in less bugs in production. If an issue is found in production, it is also easier to troubleshoot the problem as you'll know which website it is and can immediately eliminate other potential causes, allowing developers to find and solve problems faster.

Better Performance

Having your websites separate means that they run independently of one another. They could be hosted on the same web server, or hosted in their own dedicated environments. Even if they are hosted on the same web server, if one website crashes due to an issue in code, it is unlikely to affect the other. Websites also have a specific limit on how many concurrent connections they can have, so segregating the traffic allows you to balance that load over multiple applications.

Shared Web Server or Dedicated

If deciding to have a dedicated website for your microsite, you also need to decide how you'll handle the hosting. If you have both websites on different web servers, then they are entirely decoupled and will not affect one another if one is under high load or has a memory leak from a bug in code. However, if they are on the same shared web server environment and one website is using up the majority of the resources, the other site(s) will also be affected.

If you are want to reuse your existing web server, then you need to consider whether the this new site is going to dramatically increase traffic. If so, you'll likely need to scale up your existing hosting environment to support that. Scaling up typically involves doubling your existing compute power. 

If you want to use a separate dedicated web server, then this can be scaled up independently to meet your traffic requirements.

Note: Having many smaller web server environments are often cheaper than having one large one.

Multiple Teams

If you are considering having a different development team working on your microsite (than the rest of your site), then it is recommended to have a separate website. This allows you to better understand which team is responsible for what. It also makes maintaining the code base much easier as that doesn't need to be shared across teams.

 

Requirements

If proceeding with a New Website, you'll need to have this setup as a New Channel, in the existing instance or in a brand new instance. It will also need to have its own domain/subdomain.

 

---

 

Solutions Comparison

Below is a table to highlights the benefits you get with specific combinations of Same/New Instance, Same/New Channel, Same/New Website.

• Existing Website = You will be using the existing Agility instance, and building your microsite within the same sitemap tree of your existing website, using the same application code base, on the same web server
  
  
• New Channel = You will be using the existing Agility instance, will be using a brand new Agility channel/website tree for this microsite, and using the same application code base, on the same web server
  
  
• New Channel, New Website = You will be using the existing Agility instance, using a new Agility channel/website tree for this microsite, a new application code base, hosted on the same web server or a separate dedicated web server
  
  
• New Instance = You will be using a brand new Agility instance, using a new Agility channel/website tree for this microsite, a new application code base, hosted on the same web server or a separate dedicated web server

Benefits	Existing Website	New Channel	New Channel, New Website	New Instance
Reuse Page Templates and Modules from current website	Yes	Yes	Yes, Code for these must be copied to new application and maintained separately	Yes, Code for these must be copied to new application and maintained separately
Reuse Content from current website	Yes	Yes	Yes	Yes, Content must be accessed through REST API
Deploy code updates without affecting your current website	No	No	Yes	Yes
Handle traffic spikes on microsite without affecting the rest of the current website	No	No	Yes	Yes
Ability to scale microsite independently	No	No	Yes	Yes
Host on a separate domain	No	Yes	Yes	Yes
Ability to have a different development team manage the microsite	No	No	Yes*	Yes

 *When using separate development teams in a single instance, special care must be taken to ensure Development Team A does not introduce a breaking change to a content schema that affects Development Team B without their knowledge.