With Kentico Cloud (a headless CMS) you have plenty of flexibility, as every headless focused architecture is based on microservices and their many permutations. To give you at least some ideas and maybe more clarity on how to architect a Kentico Cloud project in AWS (Amazon Web Services) I’ve prepared the following diagram. There are three main sections in this diagram. From bottom to the top it’s Kentico Cloud, other third-party services (for illustration purposes), and the AWS infrastructure.
Here is the Kentico Cloud part (focusing on the feature set side of things):
I won’t go too much into the technical details of Kentico Cloud, as there is already a detailed architecture article on this part of the diagram available.
I’ve included a few sample third-party services in this diagram to demonstrate that there are plenty of other services which can be used in conjunction with Kentico Cloud, even though this setup is primarily focused on using AWS services.
There are many resources covering third-party integrations on our blog already, such as Slack webhooks, Stripe for payments, Algolia search, and more. Most of these are accomplished by leveraging Kentico Cloud or third-party app webhooks. Other possible approaches are using Kentico Cloud webhooks and a middle layer (not pictured) for business logic, such as Lambda functions, if the target third-party app lacks webhook support. Some integrations can be completely detached or front-end only. A typical example would be Optimizely.
The last part is the Amazon section of the diagram, which for illustration purposes, includes a wide range of available services.
Now in most cases you’ll end up with only a subset of these services in your final project, however to showcase how flexible a microservices driven architecture is, I’ve included a few of them. Let's walk through the diagram and break it down a little bit further into the network layer, the application itself, core AWS services, and optional modules.
User requests are served through the network layer in the top right corner. This layer is responsible for IP filtering if required, caching of resources within the CloudFront service and connects to a load balancer to autoscale if necessary. Please note that Kentico Cloud related resources are already cached within the Fastly CDN, so this would be a caching layer for other resources, like your HTML output or CSS files, or it could be placed on top of the native Kentico Cloud Fastly caching.
The application itself is pictured in the upper left corner, demonstrating the flexibility of such a setup, pictured with a multi-instance setup. These applications are framework agnostic, so it’s up to you which frameworks are hosted in this section of your setup. You could be running a Node.js, .NET, or other back-end framework. This part of your setup is usually responsible for the business logic.
Core AWS Services
In between the Network and Application part you’ll find core AWS services for storing assets, which are not content related, in S3, or in ElasticCache. Since this is a microservices driven approach to architecture these can be swapped out by other services and may not be required at all.
The above mentioned services can also be utilized by Optional modules pictured at the bottom in this part of the diagram. For example to enable search, the Cloud Search service may be utilized, or for additional business logic Universal Lambda functions may be connected through an API gateway to other none-AWS third-party services, such as notification gateways, or as mentioned above, Slack or Zapier apps.
Bringing it all Together
The three main parts above are connected via a developer friendly RESTful API. There is also a set of SDKs for Kentico Cloud, which make implementing this part of your setup easier.
All requests are fed through the inbuilt Fastly CDN which is natively used by Kentico Cloud without any need for configuration or setup. All responses are in the Json format, so working with the responses is straightforward. To give you an idea how a setup in AWS may look, let's say we need to push content to a couple of channels like smartphone applications, a mobile display setup, and a more traditional channel such as a web.
The Flow of Content
With the above setup in mind, let's follow the flow of content and what's happening under the hood of your setup.
Editors can use Kentico Cloud to collaborate on refined content, which is perfectly fits your content strategy. Once they hit publish, it's automatically propagated through your infrastructure.
The webhook from Kentico Cloud fires, and an Amazon Lambda function updates the search indexes in Elastic search. The same event triggers a different webhook for cache refresh. The content is then be pre-cached in Elastic cache for the web channel with the appropriate formatting in mind.
The display panes fetch a subset of the content live with an HTTPs request. The mobile apps retrieve content depending on the demand with the use of a REST call to retrieve the content itself.
The article which is being published this way has a short section at the bottom which recommends related content powered by the Personalized Content Recommendation Engine in Kentico Cloud. The use of API is straightforward on any of the mentioned platforms.
We've built our API for developers, and we actively work on it to make connections to other systems as seamless as possible. The great thing about approaching your next project with a microservices architecture in mind is the flexibility of it. If ever the need arises to swap out a part of such a setup, the change is probably minor compared to changing an built-in component of a traditional CMS. A microservices driven architecture makes replacing parts of your setup easy. A real life story of this was told by MVP Andrew Thompson.
Let me know if you have any other AWS services you'd enhance this setup with in the comment section below or get in touch if you are considering an AWS hosted setup, and we can help you to fill in the blanks. Happy architecting!