Your Questions Answered - '3-Tier or 2-Tier'
With the v8.5 release of Ektron comes the ability to develop and deploy a website using a 3-tier architecture, comprised of a front-end for presentation logic, middle-tier for business logic, and a data-tier for data persistence. In recent developer webinars, I've covered both the 3-tier basics (Ektron & the 3-tier Architecture) and the advanced topics (Advanced Development in a 3-tier Architecture). In this blog post, I'll answer one of the most common 3-tier related questions by helping you to understand when to use 3-tier architecture, and when not to.
Using v8.5 doesn't "make your site 3-tier" -- if you upgrade to v8.5 from a previous version, your site remains 2-tier. If you develop a new v8.5 site following the approach you have for previous versions, your site will be 2-tier. If you're still trying to understand the differences between a 2-tier and 3-tier architecture, see the previous webinar links for some helpful information.
Choosing the Right Architecture
Some have asked if it the decision should be a function of the size of the deployment, or based on the number of site visitors accessing the site, etc. The reality is, it's not really a function of a single variable, like the size or usage of the website. You might have a very large deployment that remains a 2-tier architecture. You also might have a small marketing site that could be a good candidate for the 3-tier architecture. The following list will help guide you through the process and help you to understand which is the best fit for your project.
Question #1: Do I have requirements that depend on the 5 characteristics of the 3-tier architecture?
In some cases, the decision to use 3-tier will be based entirely on requirements that necessitate it. The five attributes of a 3-tier architecture:
- Security - Some organizations, such as financial institutions, have network policies that state that the forward facing website cannot communicate directly with the database. These organizations require the database to sit on a network that is unreachable from the forward facing website. In cases like this, a 3-tier architecture is a requirement because it satisfies this network policy, since the forward facing front-end website only communicates with the middle-tier and has no knowledge of any database.
- Scalability - You might be developing a marketing website that needs to be able to handle spikes in seasonal traffic. To satisfy this requirement, you may need to scale out the number of front-end machines available on short notice. Since the front-end has a very minimal Ektron footprint (no Ektron installation, few DLLs, no workarea), scaling horizontally is very simple. For example, using Amazon EC3, you can easily scale horizontally by spining up new machine instances of your front-end.
- Performance - To minimize the chattiness between the front-end and middle-tier servers in a 3-tier architecture, Ektron provides a caching layer that sits just below the Framework APIs and resides on the front-end. This layer handles the transparent storing, retrieving, and expiring of its data. Technically, this caching layer is also available in 2-tier architecture -- but it's something to keep in mind while working with 3-tier in particular, given its role in minimizing network requests to the middle-tier and improving performance.
- Availability - If you have particularly high uptime requirements, you might consider 3-tier for its ability to serve cached data from front-end memory, even in cases where the middle-tier or database are unavailable.
- Interoperability - Using 3 tier opens up the possibility of using any web application framework on the delivery tier, such as ASP.NET Web Forms (Web Application), Web Forms (Web Site), or even ASP.NET MVC. The service layer can also be consumed by any front-end application that can communicate with WCF service layer (Java, etc).
Question #2: Do I have requirements that prevent me from using the 3-tier architecure?
3-tier & eSync: When you develop and deploy Ektron in a 3-tier architecture, you have to keep in mind that the front-end machines do not have a full ektron installation. The full Ektron installation exists on the middle-tier, which is where eSync resides. This means you can move content, assets, page builder pages, etc. just fine from a Stage environment to the middle-tier in a Production environment. However, since eSync does not reside on the front-end, you need to consider alternative eSync configuration to move images, assets, and code from a staging environment directly to a production environment. You can watch this webinar for more information.
3-tier & PageBuilder: Again keeping in mind that the front-end does not have a full Ektron installation, you cannot author PageBuilder pages on the front-end machines.
PageBuilder authoring needs to happen either:
- ... on a staging environment and then use eSync to move your PageBuilder Pages to the Production environment.
- ... on the middle-tier of the production environment. In most cases, this would not be possible since this is not on a public network, however some Network Operations folks might consider offering access to this using a VPN.
Question #3: Do I have the technical chops to develop in 3-tier?
Have you ever developed a 3-tier web application before? Do you understand the benefits of the 3-tier architecture? While the 3-tier architecture certainly simplifies a number of things for an Ektron deployment (for example, the minimal foot-print on the front-end), you have more moving pieces to consider during development and testing. While the Framework API hides the Windows Communication Foundation (WCF) Service layer, you should have some previous familiarity with using WCF and the Unity Application Block, which is a dependency injection framework used by Ektron in the implementation of the cache layer.
Question #4: Do you have the budget to develop in 3-tier?
Beyond the license cost for Ektron, you'll have to consider the cost of provisioning the additional hardware and OS for your front-ends. Though the cost of physical hardware might be potentially mitigated by using virtualized front-ends in a Production environment, you need to consider how this will affect Staging and Development environments. Will you need to mirror the hardware of your production environment in staging?Additionally, if you're implementing your own 3-tier service layer, this could increase implementation costs, so it requires considering more than just hardware.
Summing it Up
There you have it -- these are the questions that I usually ask someone to help them guide them down the path of choosing between a 3-tier and 2-tier deployment. Making the right choice for your project boils down to understanding the benefits and limitations of the 3-tier, recognizing the strengths and limitations of your own technical abilities, and understanding the budget for your project. I like working with the minimal Ektron footprint on the 3-tier front-end, so will choose to use it even on smaller sites -- provided that -- the requirements match up, and it makes sense from a content deployment standpoint (with eSync, PageBuilder, etc).
Do you have anything to add to this list? Let me know in the comments!