Why Your Sitecore Installation Costs Too Much
Vasiliy Fomichev
In Architecture, Infrastructure Posted April 08, 2021
Sitecore has been in an interesting position, tackling Adobe on the enterprise end and defending the mid-market play from EPI, or now – Optimizely. It is a one-stop shop for smaller companies looking for a centralized sophisticated enterprise-grade platform that they would not outgrow and a “microservices-based” pluggable flexible, scalable, and customizable enterprise platform. It is indeed hard to have a dual identity, as it comes with some baggage, like potential misunderstanding, misuse, misconfiguration, and, as a result, negative customer experience.
Let me start by setting one thing straight – Sitecore can be run extremely cheaply. To give an example, I ran a Sitecore XP 9.1 instance on a single Azure VM with a JSS setup for a while for $60 a month. Of course, I didn’t have the redundancy, scalability, backups, disaster recovery, and so forth; however, it was a fully functional Sitecore XP environment. Let that sink in for a few seconds.
Unfortunately, too many brands end up with misconfigured installations in the sense of size and scale. The problem is that Sitecore’s architecture has become complex, and with vendors racing to the bottom, most resort to simply using the reference architectures and sample templates provided by Sitecore. This is the story with PaaS, where in the Azure Marketplace you get a scaled instance without any questions, the same with Sitecore XC, where you got extra Ops and Minions apps for no reason by default, and the same is about to happen with containers. Sitecore has two templates for containers: you either get a single instance, called XP0 or a fully scaled XP1 with 12+ instances of Sitecore playing various roles.
Sitecore XP scaled environment architecture.
These large setups are fine for massive implementations with high traffic and sophisticated marketing tool configuration and automation; however, they are a complete overkill for most brands, yet, found in too many companies. It is no surprise that Sitecore started getting a reputation of having a high total cost of ownership on the IT side – brands end up with massive footprints on the infrastructure side, which not only costs money for the extra hosting fees, but also more effort on the maintenance side. In some cases, I was able to consolidate the setups and saved customers 80% on their hosting cost!
I recently heard someone from another Sitecore implementation partner company mentioning that containers were more expensive than PaaS on the hosting cost alone. That made no sense logically, as moving to VMs from PaaS generally cuts about 40% on hosting, and containerization allows us to use compute resources much more efficiently than VMs, so I challenged the person. His argument was – “have you tried setting up XP1 on your local machine? It brought my 32GB high-performance development machine to its knees. I’ve never seen anything like that before.” Guess what architecture he deployed? XP1 scaled. Yes, it will indeed bring the fastest machine to its knees, because it creates 12 separate Sitecore instances executing various roles, plus other supporting containers. The disappointing part was that this was an argument with an experienced Sitecore architect.
There was a lack of containerization experience at play there, but yet again, it proves the point that vendors are so used to using Sitecore’s installers and scripts that they forget – they are samples and take them for granted without taking the time to do it right. The truth with containerization, AKS in particular, is that containerization allows us to have redundancy even with a single VM, so we can run simple Sitecore setups with more than one CD on a single VM and yet have zero-downtime deployments and the 99.9% SLA on the cluster for only $73 a month, as of this writing!
Well, there is a problem here, but is it the platform? Clearly not, because, remember, I ran the whole DXP with the xDB for $60 a month.
Are implementation partners to blame for not properly tailoring installations? This seems plausible at first; however, let’s break it down.
Implementation vendors are under immense pressure to get things done faster, better (higher quality), and cheaper, all at the same time. Remember, development is a commodity nowadays, and when brands ask vendors to satisfy all three criteria, Sitecore scripts fit the bill perfectly –
- Faster: Sitecore turn-key templates and scripts allow setting up an entire Sitecore production environment in under 30 mins.
- Better: The scripts are based on a reference architecture that has been tested by Sitecore and proven to be stable and optimal.
- Cheaper: Because it now takes 30mins. instead of a week to set up an environment, the cost to the client is reduced dramatically.
Using scripts also benefits implementation partners in other ways, like taking the liability off. If things go wrong due to the architectural design, all eyes are on Sitecore and their Support, instead of the partner, who implemented the solution. So Sitecore setup scripts present an option that is the best for both worlds in the short term, where many vendors live, unless they stick around for Managed Services later. In some cases, these scaled environments get optimized later, like in the case I mentioned above where we cut the cost by 80%; however, most implementation partners do not stick around past the initial release long enough, and internal teams don’t know better. This is one of the reasons why it is crucial to perform periodic audits and health checks on the Sitecore setup as vendors come and go and your staff rotates.
This approach to Sitecore environment setups has been created by the market demands without proper checks and balances. Sitecore solution partners would be happy to do tailored configurations and customize Sitecore scripts for each individual brand, as at the end of the day, it would result in more work for them, thus, higher revenue. It is simply difficult and expensive to compete with that approach. Imagine a procurement department comparing bids of multiple vendors where all estimates are based on scripts, thus having lower costs, with one vendor deciding to do it right and submitting a higher bid accompanied by a long story justifying that cost. Ever heard of the “the odd one out” rule?…
The only way to remain competitive, yet offer the tailored approach required, vendors have to make significant investments in customizations and automation to deliver properly configured setups that are cost-efficient. I’ve always been an advocate of this approach and have always pushed my teams to innovate and create IP that would allow us to deliver more value to our clients at competitive prices. I firmly believe that the success or failure of Sitecore within an organization is in the implementation partner’s hands. This is easier said than done, especially with COVID reducing the revenue for many partners, thus reducing their ability to invest in R&D. However, there are certainly those with pockets and margins still wide enough to support this approach, who go the extra mile to drive value for their clients – you know who you are; thank you for doing what you do!
At times, clients understand the “shortcuts” they take initially with the installation and plan to have a phase two, where they envision themselves tuning the infrastructure and reducing the hosting based on utilization, but that phase gets overshadowed by other initiatives that move businesses forward, so the footprint sticks. As the old saying goes, “Nothing is more permanent than a temporary solution.”
What Sitecore clients can do to protect themselves
So how can brands protect themselves from overpaying for Sitecore hosting? I see a few options –
- Avoid discarding proposals with higher costs and consider the reason
Remember that many will try to take the lowest-cost route, especially with the T&M model, so ensure that you have qualified technical resources to check the detail in addition to simple cost comparison.
- Challenge implementation partners on providing architectures optimized for the total cost of ownership from the start
Be especially cautious of proposals depicting the default Sitecore scaled setup and question the need for such an expensive and robust architecture. There are profound benefits to having that type of architecture; however, you may not need it from the start and grow into it later, if ever. One caveat here is that to be able to challenge a vendor intelligently, there needs to be specialized talent onboard. If a brand is new to Sitecore, it is best to consult with Sitecore themselves on the proposed, or even better – hire a freelance architect who has extensive experience with Sitecore installations for a short period of time. It’s a small price to pay for large potential cost savings.
How Sitecore can help
Although we have proven that the platform is not at fault here, there is one small step that the company can take to help mitigate this problem – create a middle-tier architecture and scripts. This is where most brands fall.
It is unfair to ask Sitecore to create various types of templates, because the number of possible Sitecore topologies is quite large; however, it would be reasonable to ask for an option in between, which will help a large number of Sitecore clients get installations closer to their desired requirements. It’s asking Sitecore to take the route Microsoft took with ownership, when they noticed that developers were writing apps with poor support for older versions of Windows, so they changed the way Windows ran when certain apps were open to make sure users still had a positive experience.
Will SaaS solve this problem?
There is a lot of unknowns here; however, the TCO will be a lot more predictable with this model, and the pluggable architecture of integrated service would provide more optimized options for running Sitecore where CaaS, XM, personalization, commerce, data, and analytics come a la carte. I’m rooting for Sitecore to set up a cost-efficient yet scalable architecture, which would eliminate these concerns altogether.
