We built our new site using Kentico Cloud (and a few other microservices)

Headless CMS, microservices, serverless, SaaS, PaaS, IaaS, WTF

The buzzwords and TLAs start to get out of control very quickly when you're discussing the latest web application architecture trends, particulary when it comes to cloud-based services. In the context of this post, assume they're mostly just different ways of saying that we selected the tools we wanted to use for each of our requirements and integrated them with each other, rather than picking a single 'all-in-one' solution.

Microservices doesn't have to be an all-in approach (please don't throw things at your screen if you're a microservices architecture purist) - you could still have one more dominant platform, and plug in lots of smaller services, such as Google Analytics. In reality, most projects we implement are roughly like this. They are not truly all-in-one, even if the CMS platform carries a lot of the weight. They tend to follow more of a 'hub and spoke' structure where a central platform fulfils most requirements.

But I could go on and on about this all day. To the point... 

Why headless CMS?

Many of the reasons you would choose a headless CMS to fulfil your content management requirements revolve around multi- or omni-channel benefits. While this is certainly attractive to us, and we definitely have plans... 🙊 the fact is this website project was just that: a website project. There were definitely still some compelling reasons though, namely:

1. A content strategist on staff who focuses purely on content (which we think is awesome)
2. A very picky team of designers and developers who want/insist on full control over the presentation
3. Some cool SaaS products we've been wanting to use for a long time
4. A CTO with a point to prove! 😜

Point 4 was obviously a pretty strong one in the list too, I have to admit! So perhaps the more relevant question is:

Why not a traditional all-in-one CMS?

We're established experts in implementing some of the big-hitting CMS platforms - Kentico, Episerver, Sitecore, Umbraco... so why not this time?

Firstly, and simply: been there, done that. 😎

But also, we were in a great position to take a punt and try something different, that also meets our needs perfectly. We certainly didn't ignore our requirements and dive right in (see the process section below). We're always searching for the latest and greatest tools and technologies to apply to digital marketing, so implementing a microservices approach is almost like dogfooding for us (in terms of implementing for ourselves what we recommend for others) while also getting to play with some cool new toys!

This is certainly not a 'headless is the best, chuck out the rest' moment – we'll continue to advise for established, traditional CMS implementations where they are a better approach. This just arms us a little better to recommend microservices and headless with some rock-solid experience behind us as an agency, and as a client.

Now let's get back to us building our new site using Kentico Cloud!

The process

Roadmapping

Just as we would with any new client project, we started by pulling together a group of stakeholders and running some requirements workshops. At this point, the platform decision had not been made, and I can honestly say I didn't know which way it was going to go. We love being in this situation - being able to go into roadmapping sessions with no preconceptions about what platform we have to build on.

There was no shortage of ideas when it came to workshopping our new site.

Platform selection

Once we had the requirements sorted out, and a roadmap from here to launch (and well beyond), we were then able to pick a platform that satisfied those requirements. Or in this case, a suite of services which would satisfy our requirements, and would play nicely together.

Let me tell you, this is no easy task. (Luckily for us, I find this kind of task to be highly enjoyable.) There are very good reasons why people often tend toward an established platform with a full set of proven components that work together right out of the box! If you follow the process however, like we did, you can select a set of proven components, ensure they work together with a little encouragement, and build your awesome space lion super robot platform of your dreams.

Initial wireframing and content planning

A huge benefit we're seeing with our Kentico Cloud projects, and having the CMS fully operational from day one, is that designers, developers and content editors can work right from the start on structuring content. Throughout the UX and wireframing process we had Google Sheets running tracking the different content types, how they related to each other, right down to the expected length of text fields, whether they were required, and whether they were plain or rich text. 

Design, development and content

No, I'm not getting lazy. These items don't get their own headings this time. We really did undertake design, development, and content entry at the same time. Lucky for us, because like every client in every project ever, we set some pretty tough deadlines for ourselves... 😛

No sooner had a content type been nutted out in the spreadsheet, than it was created in Kentico Cloud, and our devs were able to actually use it in their code while developing, and test their work with real content (rather than one or two neat paragraphs of Hipster Ipsum).

I've gone on and on about this benefit of a decoupled headless approach to projects. It continues to prove accurate!

Revisit platform selection... 😕

OK, confession time. There may have been one little microservice (one of the extra non-Kentico-Cloud pieces) that turned out to be not quite as awesome as the rest. I'm not going to be rude and name the product in this post, so let's just say it was supposed to be handling some pretty important stuff for us – online forms and email marketing. Uh oh.

This actually turns out to be a big benefit of having employed a microservices approach, however. Imagine if you had invested in a behemoth all-in-one platform on the understanding that it was going to make all of your wildest dreams come true, only to find out a few weeks before launch that a significant feature was not going to cut it. One you really needed; one that was kind of the reason you chose it. Too bad, you can't change platforms now.

In our case, sure it added an extra day or two to the timeline, but we just switched that service out for a better alternative. Boom. It's morphin' time.

The architecture

So where does Kentico Cloud fit into this whole microservices picture?

The interesting thing about headless CMS projects is that the CMS is no longer the hub, or central component in your architecture. When implementing a traditional CMS, it satisfies many of your requirements and fills multiple gaps, one of them being the website itself.

For us on this project, the website is still at the centre, but the CMS is just one service the website uses.

The full list:

• .NET Core MVC – the technology used to actually build the luminary.com site
• React.js – a touch of listing and filtering magic here and there on the front end
• Azure Web Apps (and Deployment Slots) – hosting and continuous delivery
• Kentico Cloud – content management, analytics
• Kentico Cloud's Recombee integration – machine-learning based content recommendations
• Algolia – site search
• Breezy HR – job listings
• Azure Functions – updating search indexes
• Zapier – integration with internal systems
• CloudFlare (including the awesome new Edge Workers!) – network optimisation and delivery
• Formstack – forms and gated content
• Youtube – all embedded video content
• Campaign Monitor – email marketing and automation
• And more that probably don't deserve to go under 'architecture' (via Google Tag Manager) including:
  • Google Analytics
  • Facebook
  • LinkedIn
  • Adwords
  • Hotjar
  • IPTrack

Some of these are more obvious than others. If you're scratching your head over exactly how any of these fit into the picture, that's probably outside the scope of this article (which is ostensibly only about Kentico Cloud). Grab me for a chat some time, I could talk for hours on each point!

The Kentico Cloud experience

I've talked a lot about general microservices and headless CMS project experience here. But this article is supposed to be about building a site on Kentico Cloud! First I just needed to get across that it's not as simple as that, when you're not using a traditional CMS as your one-stop-shop solution.

So, disclaimers aside, what was it like, building a site that uses Kentico Cloud as a headless CMS?

In a word, from my point of view: fun. 🎉

Pros

• Content import (such as blogs from old site) happened first, not last, which was great for design and development.
• It gave us the freedom to choose whatever other services we wanted, such as Algolia search and Campaign Monitor for email marketing.
• Minimal hosting requirements (we're on an S1 Small app service in Azure and using next to no resources, handling traffic with ease)
• Terrific support from the Kentico Cloud team. You can literally start live chat on kenticocloud.com and expect a reply within minutes.
• Our entire team of around 50 staff were able to edit and review their own content throughout the whole process, without feeling like they had to 'log in and edit the site', because it didn't even exist yet!
• Changes, fixes and improvements (using CI and CD) are super quick and easy since we can update any little piece on its own without bringing the site down or interrupting traffic. We have true zero-downtime deployments, even through major changes and version upgrades.
• Designers, developers and content editors were all speaking the same language and working very closely to produce the site, rather than complaining about or defending CMS limitations. But by the same token...

Cons

• Designers, developers and content editors all need to speak the same language and work very closely to produce the site, rather than having the luxury of following CMS standard practices.
• There were lots of moving parts/puzzle pieces when pulling the whole thing together. If you're not extremely well-equipped to deal with it like we are, there's definitely still a benefit to going for an all-in-one solution such as Kentico EMS, as even though you didn't get to choose all the pieces, you know they are all guaranteed to work well together.
• Learning curve: pretty much everyone at Luminary is highly experienced with Kentico EMS or other traditional CMS platforms, so there was new stuff to learn, and old habits to unlearn.
• Surprises! Even with a lot of planning, we learnt right toward the end of the project that a critical piece of our marketing tech stack wasn't going to meet its requirements. We were able to switch it out, but it added tasks to the critical path to launch at a time that was not ideal!
• We had a super picky client. 😤

Overall

• We produced the site we wanted, without being held back by a CMS or any other technology.
• It performs really nicely, and our hosting costs have dropped.
• We're using a bunch of tools we've wanted to try out for a long time but weren't part of our existing CMS platform.
• Maintenance and deployments are a breeze.
• Developers had a great time playing with all the new toys!
• Our team, from content strategist to designer to developer, learnt a lot about how to work with microservices and a headless CMS.

Overall, it was definitely a resounding success.

Final thoughts/warnings

Remember, you use a headless CMS as part of a larger set of tools. It's one service in a larger suite, or architecture. You don't 'build your site on the Kentico Cloud platform'. (Notice the title of this post says 'using', not 'on'?)

A microservices approach requires good tech people to set it up right, whether they're in your own team, or from an agency with experience (like ours).

If used properly, a headless CMS and a microservices approach can truly open up a huge range of opportunities that just aren't possible on traditional all-in-one platforms.