I spend quite a lot of time thinking about and planning how services should fit together. APIs, databases, identity, messaging, resilience, networking, monitoring. All the usual boxes and arrows. But occasionally there’s another box on the diagram:
When presented with that, my natural response is this: does it actually need to be here?
In a lot of cases, the best decision you can make about your public-facing website is to keep it well away from the rest of your architecture.
Your marketing website probably isn’t your application
Let’s say you’ve built a cloud platform for your business. Customers log in. There are APIs, services, databases, authentication and all that other stuff. You know, the infrastructure required to actually deliver the product.
But you also need a website.
It needs an about page, pricing, case studies, contact forms, and whatever SEO stuff you need to get it to the top of Google (don’t shoot me; I’m a cloud architect, not a marketer). It’ll probably need a blog and some reasonably nice (and definitely not stock) photographs of people using your product.
It’s tempting to think that because both things belong to the same company, they should also belong to the same technical platform. Some people will say that they don’t necessarily need to. Personally, I think that in most instances, they shouldn’t.
Your application and your marketing website are there to do very different jobs. And they have different requirements. An application might use complex authentication, controlled deployments, private networking and carefully designed resilience. A website needs someone in the marketing team to be able to change a heading without taking a dev off a more important job. Those are not the same.
Don’t turn a brochure site into a software project
I’ve seen businesses apply application architecture thinking to websites that don’t need it. If it’s just a marketing site, you can be fairly certain it doesn’t. Making that mistake suddenly means the company website needs a whole load of extra stuff. A frontend framework, a headless CMS, several cloud services, a CI/CD pipeline. Oh, and a team of developers who understand the whole stack in order to add a new landing page.
None of those technologies is inherently wrong. There are, here and there, websites where that architecture makes complete sense. But if your requirements are those of a normal website, you’ll want it to do the following.
- Explain what the company does
- Publish useful content
- Generate enquiries
- Rank well in search
- Be easy to update for non-technical staff
If that’s it, then what is all that extra architecture building for you, other than complexity?
A web developer might actually be the better choice
For a normal public-facing website, I’d seriously consider treating it as its own project. Find a good freelance web designer or developer. Put the site on an appropriate managed hosting platform, and use a sensible CMS. Then give the people responsible for the website content the ability to actually use it.
You can still integrate it with the main platform where there’s a genuine reason to. If the site needs to send enquiries into your CRM, or your pricing comes from an API, for example. No bother at all. An integration doesn’t mean both systems have to become one system.
Keeping that boundary clear can make both sides easier to manage. And both your marketing and dev teams will thank you for reducing the friction of both of their roles.
You get a smaller blast radius
There’s another advantage which doesn’t get talked about enough. Things break. Deployments go wrong, services fail, credentials expire, cloud providers have incidents. Blah, blah, blah. One day, someone might change a configuration setting only to discover that it was way more important than it looked.
If your marketing website is separate from your application platform, your entire online presence won’t disappear when your app goes down. Your application might have an incident, but the website will continue working. This leaves you somewhere to communicate with customers.
On the flip side, someone redesigning the homepage won’t be in a position to accidentally interfere with the infrastructure responsible for running your core product.
Separation can be useful.
There are absolutely exceptions
Despite what I’ve said about this being the best plan in most circumstances, it’s not something that I’d make a hard rule. If the website itself is deeply connected to your application, integrating it into the wider architecture may be sensible. It may even be essential.
Perhaps page content is generated dynamically from platform data. Or authenticated and unauthenticated experiences are tightly connected. It may even be possible that you’re operating at a scale where a shared frontend platform makes development much easier.
There are valid reasons for that approach, but “we already use AWS” isn’t one of them. Neither is “our developers can build it”. Yes, they probably can. But is it a valid use of their time? Is there not something better they could be doing? Just because someone can do something, it doesn’t mean they should.
Architecture is partly about knowing what to leave out
There’s a tendency in technical architecture to concentrate on how we should build things. One thing that I always bring up during planning stages is this: Does something need to be part of the architecture at all? Don’t overcomplicate things.
Your core cloud platform may be complicated because the problem it solves is complicated. But that doesn’t mean your company website needs to get involved with that complexity.
Sometimes the sensible solution is remarkably mundane.
Find a competent web developer and give them the website. Then let your cloud architecture devs concentrate on the things that actually need cloud architecture. They will no doubt thank you for giving one less annoyance to worry about.