My name is Saber Karmous. I work as a Software Architect / Consultant at Aviva Solution, but I prefer the term Software Artist. At night I transform into Darkh Saber.

9 grievances that make Sitecore development a challenge

¿Qué Pasa con Sitecore?

New Sitecore features and functionality seems to be released faster and faster these days. Especially since the release of Sitecore XP 7.5⁄8.0, it seems that with every blink of an eye there’s a new module like the Sitecore Experience Accelerator or components like the publishing service being introduced. But with the introduction of Helix, Sitecore is also taking the way Sitecore developers do their work a lot more seriously. Finally there is some guidance, best practices & architecture : Helix and an example implementation in the form of Habitat.

But even with the Helix guidance there’s a lot you can do wrong or have to figure out for yourself. The most important one might be the setting up of a Sitecore Helix solution and bringing it in production AND maintaining it. Once a solution is released to production a project doesn’t end. I actually think that part of doing a project should be doing a couple of releases to production before it goes into a maintenance phase. I doesn’t stop if you deployed to production just once.

So without further ado. Keep reading if you’d like to know what my 9 grievances are with Sitecore development and how they could be improved to make the world a better place.

The opinions that I write here are of my own. I might offend someone, but this blogpost is mainly to rattle the feathers within the Sitecore community. I’m NOT trying to get personal. I’m doing a couple of observations that, in my experience, are shared by a lot of Sitecore developers. Nonetheless if somehow you’re offended contact me through Twitter (SdotOne).

1. Running Sitecore in Azure PaaS can’t be all that hard

If you read all the blogposts (props to Bas Lijten en Rob Habraken) and the information on the Sitecore site about running Sitecore in Azure PaaS, you’d actually believe that running Sitecore in Azure is a piece of cake. WRONG! On paper a PaaS solution should be easier for as well as the software developer as the ops girl/guy. In other word DevOps should take a lot less time. Unfortunately Sitecore, in its current state, needs to be treated very delicately if it’s going to play along in the PaaS game. There’s a great deal of moving parts to deploy Sitecore (the easy part), you’re custom code (quite easy) and repeat that (the tricky part) to Azure PaaS. So my advice is to really read those blog posts bij Bas Lijten en Rob Habraken, and take your time!

One of the hardest things in software development is distributed computing. There are all kinds of architectural patterns that more or less help to solve this: service oriented architecture, microservices, DDDD, hexagonal architecture and the list probably goes on. Those are all hard to get right. And you might ask, what have these things to do with Sitecore development? You might not even ever heard of any of them. Well, they almost all have in common that they help to create a succesful cloud solution. And why? Because all of those patterns, in one way or another, took measures to make it possible to scale out. In other words these patterns make it a lot easier to migrate from an on premise solution to a cloud solution.

Now back to Sitecore. I think we can all agree that in it’s current form you can consider it a monolithic application. This might not have been a problem 15 years ago, but today if you have a cloud app, breaking up your applications in smaller modules (see how I circumvented the term Microservices) is the smarter thing to do. It doesn’t make a solution any simpler. On the contrary the cloud solutions even add a lot of complexity! Fortunately there’s are a lot of technology that can help to hide parts of that complexity, so your average Jane and John Doe the developer can focus on doing the thing they do best : building software. PaaS, BaaS and CaaS are all cloud models to help build and release software faster and in a more reliable way.

All team members of a modern software development team should have the super power of deployment. Code, run tests, let stakeholders review and approve and deploy to production. Crazy right!? Maybe. And even more crazy if you’re used to doing “traditional” Sitecore development. Just 3 years ago a Sitecore consultant was looking at me crazy when I suggested that I wanted to be able to release to production multiple times per day. Unfortunately the way Sitecore is deployed, even today, isn’t really compatible on how you release in a modern cloud environment. And to be honest it’s not only Sitecore that’s at fault, Microsoft didn’t exactly do their homework either. So what’s wrong? Seperation of Concern! You know that thing that basically says: mind your own business. Sitecore clearly violates that rule many times.

An example of one of those violations is the way you configure the hostname in a multisite configuration, I don’t want to put the domain of my application somewhere in my config, because that’s not the concern of my Solution. It’s only relevant when you deploy, and you configure it as part of the infrastructure configuration. In its current state if you want a multisite setup based on different domain names you configure that in xml/.config. That works, until you find out that the url you access your application with might be completely random in a cloud environment, or you want to load balance you’re CD server. Yes ofcourse you can configure that too using Web.config but that configuration should be on the infrastructure level, not in the application. SXA sort of does a better job, by making it possible to configure the url of a site in Sitecore itself. This still isn’t perfect because you would like to change this setting in Azure.

Oh yeah, configuration. Let’s get to that point.

2. Who put that zzzz folder in here!? Wait whut!?

That was my first reaction when I saw a zzz folder in a Visual Studio solution. And it makes sense in the Sitecore world, but up until Sitecore 9 this Excel file meant hell when you’re ready to deploy to production. Sitecore 9 introduced the more than welcome notion of configuration layers (see this very clear introduction by Jammy Kam), and that really helps a lot. But that’s not a fix for the root cause. The configuration of a Sitecore solution should be seen as a service that a Sitecore application can hook into.

I definitely pulled my hair out a couple of times when I was developing the CI environment on Azure PaaS. The configuration is still on a “boilerplate level”, I really think this should be solved by the platform and shouldn’t be the responsibility of Sitecore developers and/or Ops guys and girls. It should be possible to store configuration in a database, use the configuration service of a specific cloud platform or a custom built configuration provider. But the turn key solution should be fool proof and dead easy to work with. In 2017 XML files shouldn’t be the way you configure your application.

So yes, Sitecore 9 fixes a part of the problem, but I think it could be better. My gut feeling tells me this might be addressed in the future, when Sitecore migrates to dotnet core and will consist of a bunch of Microservices (ok, couldn’t help myself) and Functions-as-a-Services. The speedy publishing service, built on dotnet core, is an indication of that. I’m convinced that this new architecture will force Sitecore to rethink the configuration part. Think Consul, confd and etcd. These are examples of technology that make configuration play nice in a cloud and container ready architecture.

3. Frontend, who!?

I’m a firm believer of the fact that frontend development is getting a more important role in software projects. Heck I even think that the term Content-as-a-Backend should be a thing. Unfortunately those pesky containers guys already claimed the CaaS acronym. Even though Sitecore development has moved away from Webforms a while ago, there’s still too much unnecessary ceremony when creating html+css+javascript for a Sitecore solutions.

In other words, development should be turned upside down and frontend development should drive development of a Sitecore solution. Sitecore should be just a backend for the frontend. Yes I know, SXA is there to help. But I’m not really convinced that SXA solves anything that hasn’t been solved in the frontend world. And if you play by the “frontend rules” you unlock an gigantic amount of potential frontend development power that don’t necessarily need .NET knowledge to be productive in a Sitecore project.

So a welcome concept is the headless cms. And to be honest this is something that Sitecore has been mentioning before, and I really think it’s essential in the way we develop web applications. Sitecore should focus on Content Management, and make that eXperience top notch! I’ve been confronted by content managers about the complexity or lack of ease of use of Sitecore. Sitecore should really give a lot more love to the CMS UI part, and give us devs an API that does just one thing very well; serve content that might be rendered server side or client side.

In its current state frontend development seems to be an afterthought. Sitecore really seems to be having a hard time with catching up with all the frontend development technology that’s being released at an insane rate. So again focus on what you do best; Content Management. Ideally you’d run a CD in a lightweight container, so that you’re average frontend developer can spin the Sitecore backend up, and run the frontend in a seperate container. That would give frontend developers a major boost in productivity and allow them to play a significant role in a Sitecore project.

And in all honesty, the new JSS looks nice and might be the way ahead. Can’t hate on React and Redux, so that really suprised me in a positive way. Hopefully that will, in combination with Sitecore docker containers, help us to fit in the frontend development more naturally.

4. Use your tools wisely

For me the smoke around Helix is starting to clear. I just got used to Helix, but I’m not experienced enough in Helix to talk about well tested best practices. But one thing that strikes me is when I accidentily press F5 in Visual Studio to “run” the application, somewhere a cute little kitten dies. How come we’re not able to use Visual Studio how it’s supposed to be used. Visual Studio was never intented to be used as a big web project publishing machine. We should use Visual Studio for what it’s meant to do.

So what’s my beef? Well the extensibility of Sitecore is a bit odd. Yes it kinda works, but it’s a feels hackish. Publishing in development can break the Sitecore functionality because of the potential overwriting of the assemblies and config files. And due to the way Sitecore deployment should be “layered”: Vanilla Sitecore with your code on top, deploying to Azure PaaS is complex to say the least.

Anyone heard of MEF? No? Well here’s a quote, and hopefully it rings a bell.

The Managed Extensibility Framework or MEF is a library for creating lightweight, extensible applications. It allows application developers to discover and use extensions with no configuration required. It also lets extension developers easily encapsulate code and avoid fragile hard dependencies. MEF not only allows extensions to be reused within applications, but across applications as well.

Yes MEF went trough a couple of incarnations. But the point is that extensibility can be solved in a more robust and easy way than the way it’s done in Sitecore right now. I don’t want to manually attach Visual Studio to the right w3wp so I can debug. I want to code, save and see the result within a couple of seconds without accidentally break things. If you ever witness the insane speed at which an experienced frontend developer can develop a frontend application, you’ll really start to question why we’re so invested in our dreaded code->compile->publish->debug cycle. Let’s try and leverage that power and speed.

And that brings us to the next point.

5. How ‘bout you give me productivity

…and I’ll settle for a little less flexibility. I think that now more than ever Sitecore should take a more opinionated stance regarding software development and maintenance. Seasoned Sitecore developers will probably think that Sitecore development is easy peasy, but Sitecore development is a very complex endeavour. Yes it might be blasphemous to ask for simple Sitecore development, because what should happen to all the “look I got this working in Sitecore by hacking this” blogposts? One of the important reasons why you choose a CMS in the first place is productivity. And in order to be more productive the solution you build shouldn’t be overly complex.

Relying on GUIDS to "couple" between code and templates/renderings on hindsight is not that smart

Kudos for Robin Hermanussen that wrote a Roslyn thingie that can prevent you from writing code that refers to invalid GUID. But that’s not a solution for the root cause, which is that there is no way to tell that your code + templates/renderings belong together. Call it a manifest, which can be used in a bundle that contains a version (SEMVER please) and all the code + templates/renderings. That way you know what code is compatible with what templates/rendering/etc in Sitecore. Ideally there would be an automated way to find out whether the content is compatible with code + templates/renderings. Yes Sitecore is able to know whether modification of a template could break content, but it can’t tell you anything on the compatibility of the code from your late night commit.

And you know what? Why not take the code first approach for developing templates/renderings. Make the flexibility of creating templates within Sitecore optional, and as a default you should do everything in code. The only thing that remains in the database/content tree is, you guessed it, the content. And it might sound crazy, but you might not even need a tool like unicorn/TDS anymore, well at least not in development. Content is managed by content managers and code by developers. No more accidental “development content” that overwrites carefully written production content.

As you adequately put, the problem is choice. - The Architect

6. Yeah yeah, everything is an item. But where’s my page?

It seems very trivial to have the concept of a “Page” in a CMS. A Page is a concept that’s not really tangible in Sitecore. Most people understand what a Page is when they’re talking about a web application. But what we normally call a Page is represented by an item in the content tree. I haven’t been around in the dark ages of Sitecore + Webforms, but in the current Age of MVC™ it’s a very annoying omission from Sitecore that leads to all kinds of unnecessary caching and controller instances.

So what am I talking about? As everyone knows, a page is normally represented by an item in the content tree. This item has a layout, templates and renderings that are used to generate page output. But there is not some kind of “Page object” that you could use to store something.

And example to explain this a bit. You might have a dashboard which consists of a couple of renderings that use the same data, let’s say the personal information of the logged in user, coming from the backend. Rule of thumb is that every external system is too slow to run at “internet speed”. So every call to a backend system is basically a waste of time. Yes it’s necessary to have fresh data from it’s source, but it’s always slower than retrieving data from memory. So if I want to use the personal data once, one call would be enough. But if I want to use that data in say 3 different renderings every rendering would call the backend retrieving the same data, and you’d end up with 3 backend calls. Two of those backend calls would be unnecessary.

Yes, I hear you say. You could cache that stuff. Yes, that’s the first thing a developer does to “solve” the problem. I’d rather have the notion of a “Page Saga”, akin to Saga implementation patterns – variations by Jimmy Bogard. A “Page Saga” would be responsible for all the state and processes that are needed to generate the page content. In a regular ASP.NET MVC application that’s not hard to do, because rendering a page is handled by a single controller. That’s not the case with Sitecore, every rendering is represented by a controller. And since a page is represented by a template + layout + multiple renderings, there’s multiple calls to controller action methods involved with rendering a page. And no, I’m not gonna start on handling form posts, because you should be doing Web Api calls to begin with.

8. Documentation? Why? You have the code… sort of.

What baffles me is the state of documentation of Sitecore modules and the fact that I have to reach for dotPeek too many times. The first part is really surprising, mainly because the modules are pieces of software that aren’t being used as much as Sitecore itself. So documentation is extra important. Why? Because you cannot rely on experience of yourself or the community; modules like Dynamics CRM Connect or the Sitecore Experience Accelerator 1.5 aren’t used as much as the Sitecore Experience Platform ofcourse.

So more documentation and example code is welcome. Habitat is one of those gems that really is helpful for developing Sitecore solutions, but I really hope these kind of examples will be created by Sitecore for individual modules too.

9. Onboarding of new devs.

I’ll keep this short, I’d be very happy if you even made this far. The onboarding of new devs should be a lot easier. But before you even get to that point you have to find fresh new devs that are willing to dive head first into a Sitecore project. Currently there’s no way to download a trial version, or better yet a docker image, spin up Visual Studio or Rider and hack away. I think Sitecore is a bit too protective of its code. Microsoft has been supplying evaluation version of their software for ages. And they realize that it’s very important to get young and new developers to try and use their software as easy as possible. I don’t really see why this doesn’t change since the need of a license.xml should remain.

So plz Sitecore be a little bit less restrictive of distribution of your code.

Now what?

Actually I really believe Sitecore is heading the right way, maybe a bit too slow for my liking, but there’s clearly a new fresh wind running through Sitecore world. I like it. And if Sitecore keeps telling us where they are heading, us mere mortal Sitecore developers can anticipate on that. Not everyone is an MVP ;)

Since I don’t have comments on my blog, come fight me on the Sitecore Slack Community (saber is my nickname) or on Twitter (sdotone) ;). I’m very interested on what you think about Sitecore development in general and this blogpost more specifically. If some interesting thread arises I’ll link those back here.

¿Qué Pasa con Sitecore?

New Sitecore features and functionality seems to be released faster and faster these days. Especially since the release of Sitecore XP 7.5⁄8.0, it seems that with every blink of an eye there’s a new module like the Sitecore Experience Accelerator or components like the publishing service being introduced. But with the introduction of Helix, Sitecore is also taking the way Sitecore developers do their work a lot more seriously. Finally there is some guidance, best practices & architecture : Helix and an example implementation in the form of Habitat.

But even with the Helix guidance there’s a lot you can do wrong or have to figure out for yourself. The most important one might be the setting up of a Sitecore Helix solution and bringing it in production AND maintaining it. Once a solution is released to production a project doesn’t end. I actually think that part of doing a project should be doing a couple of releases to production before it goes into a maintenance phase. I doesn’t stop if you deployed to production just once.

So without further ado. Keep reading if you’d like to know what my 9 grievances are with Sitecore development and how they could be improved to make the world a better place.

I finally got fed up, I was suffering some serious “blogengine/design paralysis”. I didn’t seem able to decide on which engine and framework I should use for my own blog. But probably more important, I didn’t know what topics I should focus on. Enough is enough, I picked Hugo for static website generation, Docker to run the whole thing in a container and I just picked a theme that looked the best to me.

To prevent this blogpost to be a “Hey, here’s my brand new blog”, I’ll just tell you how I set this whole thing up, and what kind of workflow I’m using right now.

tl;dr

Creating a new blog on Medium or Wordpress is easy. But hey, where is the fun in that? I also took this route to learn some things about Docker, Docker Compose and Docker hub, Letsencrypt, and what it’s like to use a static website generator.

The key take aways

Using Markdown, a static web generator and git really translates into a Content Management System for Developers

Learning Docker is all about doing; a fairly simple thing as running a blog in a Docker container already gave me some a lots of “AHA” moments.

Since the introduction of Letsencrypt you really have NO reason to skip https support.

Open-source software once again proves that it can create magic

After setting everything up, I immediately thought that this could be automated a lot more. This is far from a turn key solution. See how you can deploy a static site with a press of a button at Staticgen.

Disqus, Google and Gravatar are all evil. Run your own, or die trying ;)

Writing good content takes time

191.96.249.42 - - [02/Feb/2017:15:06:52 +0000] “GET /phpmyadmin/scripts/setup.php HTTP/1.0” 404 169 “-” “-”… No sorry .php is not in the office today. Try https://www.phpmyadmin.net/ maybe they can help you out. G’day.