DFDS goes serverless

20180914 dfds goes serverless

This post was initially posted on www.linkedin.com.

For the past year I have been part of the new cloud first initiative of the shipping and logistics company called DFDS. The cloud first initiative is not a movement to force everything into the cloud but rather have cloud as the first option if it makes sense. If it does not, it still is alright to utilize our alternatives, like our own datacenter.

Reasons that should make the cloud the first choice can be; less maintenance, higher stability, more flexible and in some cases lower or more transparent costs.

Step one for the cloud

Because of my involvement in the cloud first strategy, I have been working on areas where we can modernize the company’s processes. An area easily spotted was our web presence.

Like many companies, we had decided to use SharePoint as a CMS for our public facing website. Looking at the trends and our increasing complexity in feature requests, this began to look like a bad choice. It didn't feel as flexible as we wished for and with Office 365 and SharePoint online rolling out, it also seemed like the on-premise version was getting less focus than before.

Something radical happened

Instead of staying on our ageing SharePoint based platform, we decided to do something radical. We wanted to jump to the front row of tech and avoid having a platform that would be outdated before it was even released. I am sure most of you can recognize the feeling of being outdated before you even deploy your code, so you should know why we would want to get ahead of that.

We tried it all: cloud, serverless, Node.JS

To achieve this, we decided to go with all the buzz words. We went cloud, we went serverless and we made a switch from .Net to Node.JS. To sum it up we were in a world of pain. Out of our comfort zone and with a requirements for skills we did not possess.

We did not aim for anything big. The goal was a simple conversion of our old page to a new facelifted one with a cleaner and more flexible code base. But all the steps we took was a challenge. First step was training and hiring people who could work with our switch to Node.JS. We also decided to go with the React library which added to the learning curve of the switch.

Angular or React?

We had many discussions about if Angular or React would be a better fit. We did have some internal knowledge with the Angular framework but still decided to go with React. When we had gone all in on trying out new tech, the argument about us having knowledge with Angular felt slim at best. Also, it was argued that React should give the end users a faster experience than Angular. It is hard to say if that assumption is still correct with our finished page but the numbers at that time seemed valid.

React matched with our newly bought headless CMSContentful’ and we decided to abandon our old jargon of creating pages. Instead we went into the business of making components.

A steep learning curve

If possible, components should be reusable and then just filled out with content from our CMS. That meant we had a steep learning curve of creating our basic components. It actually took us several sprints just to get a simple page running that had any content. But in return, once we had our basic components built, the website pages were almost created as if it was a factory.

Deciding on the serving platform

Now that we had the guidelines for building the page in place, we had to decide how to actually serve the page to the end users. Since most of our pages relied on JavaScript, we could risk getting punished by indexers that couldn't render our site—so to minimize cost, maximizing performance, give our users the best experience while accounting for SEO and care for web crawlers, we decided to go with a pre-rendering approach.

Every time a code or content change would be done, the page would be rendered by a serverless cloud function, outputted into a static HTML page and stored in a private cloud store. The full content of the store would be a non-personalized version of our website, that we pushed to a CDN, which would act as our actual web host. This gave our site the full benefit of a CDN all the way through, but using the cloud store also gave us an added benefit with version control of our rendered pages, which could potentially help out in a bad situation by offering a time-efficient rollback option. Some pages like form posts or search indexing could not be handled by static HTML. To keep features like that, we either let them stay handled by cloud functions on run-time or found managed versions of services that could be integrated with our website and get us the functionality we needed. Some examples of this would be email and search indexing services.

Benefits of hosting on a CDN

Some of the benefits of using the CDN was that we got support for HTTP/2 which meant we could serve our page as a stream instead of multiple opening connections for each content object, we got multiple endpoints our users could connect to worldwide instead of our single country endpoint before and we also got added security in the form of DDoS protection and URL injection filtering. Sounds quite expensive right? Once we went live with it the total cost was $80 a month. I would argue that is quite cheap if you take into consideration that it is a public-facing enterprise website.

A distributed, auto scaling and resilient infrastructure

All this together gave us a more or less complete version of our previous website but with no maintainence. The servers were gone and instead we had a distributed, autoscaling and resilient infrastructure that, in theory, should be able to handle any load we could throw at it. The only difference in our end should be the cost, since higher load would mean a more expensive scale up. Not much different than when we did it on-premise, except instead of going in steps of whole servers we could step up on compute milliseconds and load kb’s instead. A much more granularly scale that started off in a completely different cost bracket. Quite neat, actually.

We didn't stop at source code

Behind the scenes, we worked with VSTS where we had our GIT repositories with our websites source code and created pipelines to get our site up and running. But we didn't stop at source code. Since we purely did cloud services, we also introduced the concept of Infrastructure as Code.

Every moving part was defined as code and parameterized. This allowed us to reuse the code for every environment and just switch a few variables to define the URL, if it should be public accessible and other tweaks that made the difference from development and production. It also allowed us to multiply our number of environments in case we needed more testing or take them down, if we no longer needed them. From nothing to full infrastructure and code deployed via the pipeline took just about 30 minutes.

Some of the code was clumsy made since not all cloud services are as easy as others to provision through scripts. A rough estimate, if we decided to focus on it, we could bring the time down to about 10 minutes. But 30 minutes is still a huge improvement from our previous approach with VMs in our datacenter which usually took around a week just to get configured and then afterwards we had to deploy our code.

I am proud of what we achieved

So, we spent the better part of a year and got a page that looked just like the old one. I admit it sounds kind of stupid. But I am actually quite proud of what we achieved. To my knowledge, we didn't get much feedback from our users, neither good nor bad, which must mean that they barely noticed. I would argue that is a very big deal when pretty much everything under the hood has changed! We also switched from a mostly vendor-controlled code base to a fully flexible one. We could leave maintenance windows behind us and our time to market greatly improved. You could say we invested in the future. But it actually also seems like it saved us quite a lot of money. In rough numbers, we used to pay $1,300 a month for our infrastructure. The bill for the first month we went live with the new site was $80. Keep in mind this is our company site, not our booking one. It did take quite a lot of development hours, but I am confident we can easily earn that back in the long run now that we are in full control of our site and got all the basics in place, just ready to shoot out new pages from our machine gun of a website-factory.

We are still progressing

Our site has been running for some time now and is doing very well. New features have been added and even more will come. Since the first release we have been optimizing the page load. We didn't perform quite as well as we had hoped in the first release, but that is an acceptable blooper considering how huge a change we went through. We also added contact features and multiple languages. We have introduced cloud-based databases, email services, and more functions. This has just about made our cost 3 times up of the first release price which is still extremely low compared to our costs before the switch.

Unexpected side effects

But one of the unexpected side effects is that we are now ahead of the tech wave. Yes, serverless has been here for quite some time but did any of you try to purchase third party systems for monitoring, logging, alerting and management of a serverless platform? If the products actually do support it, it is a nightmare to figure out the pricing model since most use a pr. host model which isn't as black and white as with classic VMs.

Continuous improvement

Now that we are running live and looking into ways of improving the platform, it is the first time in my tech carrier that I feel like we actually got a platform that is ahead. It is both annoying, since it is hard to get support for this, but also a strange feeling of pride to have been part of building something like that. I am sure it is only a matter of time before it is normal to do it this way since we can see so many benefits compared to what we used to do. But I am just as sure we will continue to find new problems and issues with this approach that we need to solve. And I will continue to enjoy the challenge of overcoming these issues and defining a new way of doing web development in our company.

To sum it up: DFDS ♥ Serverless

Blog posts in your inbox

Subscribe to receive most important updates. We send emails once a month.