Building up : StartingUp

Gone are the times where we would host our websites in our dorm, garage or office on a klinky server with the electrical plug scotched to the wall with a big "do not unplug" sign on it.
Nowadays we have plenty of choices from virtual private servers to bare metal servers, we even have the possibility to disconnect even more from servers and trust a provider to run our applications within their platform without us having to worry about the servers and how to deploy the code on them.

But where can we start in all this ? The following is a take on this topic, from the point of view of a project lead for a web application with a python or ruby backend.

Check your team

You need to run the backend somewhere but you also need your team to be comfortable with the solution that will be used. Setting up ad-hoc infrastructure has a cost, it takes time, money and sweat. We don't always have the first two and we probably want to save the sweat for the bigger battle of actually getting the product out and live.

Usually, I am quite happy for my clients to go with a Platform as a Service (PaaS) such as Heroku, at least to start and get the product out there. The first months, or even years, it's better to keep hands free from the infrastructure and be sure the product is matching the customer needs and actually bringing money in. The technical team will be small and needs to be focused on the product itself. Relying on a PaaS, easy to plug in addons and third party service providers will cost money but will save a lot of time, especially to try different things before finding the mix that works.

That said, if you already have several (more than 1) people that are quite knowledgeable with Infrastructure As A Software (IaaS) providers (AWS, Google, DigitalOcean, Scaleway, ...) and their products, there might be an argument to play, but if those two people are your only two tech people it's probably a risky bet.

As many point out : first get your product out, worry about the details later once it's worth doing so.

PaaS to get going

PaaS providers are great to get started : you have very little to worry about, they come with a good, stable and scalable compute layer, usually complemented with a database layer and choice of additional SaaS addons. Heroku is the poster child of this and it does offer plenty of possibilities.

It will get your project running in very little time, give you plenty of capacity to grow and absorb the growth. Addons are easy and cheap to test out to check ideas, verify assumptions and experiment.

There are disadvantages though : you don't have control over some layer of the infrastructure such as routing and load balancing which can be a pain in some cases.

One good thing about Heroku is that you can mix and match it with other solutions. You can totally run other services on AWS, Digital Ocean or Scaleway and get them to talk with one another. As long as you set the necessary security rules and configuration you will be fine.

This is important as it does not entirely locks you up with Heroku or other providers. You can start with Heroku and slowly move away from it by replacing its web and non-web dynos (virtual server instances) with containers running on servers setup in AWS, Digital Ocean or Scaleway. You can also imagine replacing your databases running on Heroku PostgreSQL with managed ones running in the previously listed infrastructure providers.

IaaS to scale up

And this leads us to consider IaaS providers as formidable beasts to scale up once you know your product runs and is worth it.

The task might appear daunting but, as pointed out just earlier, it's something that can be done in steps. Again, knowing if your team is ready to do this is one of the biggest pre-requisites. While adding a specific service to your environments might be practical or look nifty it's always important to check if it will be used and if there are people ready to maintain it as part of their daily tasks.

Bus factors of 1 are never good in the medium and long run. I understand that making the jump to use this or that product or software is exciting for some but that excitement might bite you back pretty quickly if it's not the right time.

Thankfully we can not only do the migration from a PaaS to IaaS in steps but we can also rely on Infrastructure as Code tools (terraform for one) to document and version what we do as we go.

For my clients, moving to an IaaS is often something that is pushed back for years, but at some point it starts to make sense to have at least some side services setup and running in an IaaS. The CI/CD pipeline can be a good candidate for this. It's relatively low in requirements compared to the rest, and it's fairly easy to slice that migration too. It can be a good opportunity to test out the general architecture your team wants and prepare the grounds for the next steps.

Once a base setup in IaaS is done it's usually good to start hosting pre production environments. They constitute a good test run for the real, production, environments by having very similar requirements to it.

Just like I describe in the other articles of this series, infrastructure, whether it's in a PaaS, an IaaS or bare metal servers, is matter of team work that will evolve step by step as the team and project go.

and beyond

That's why there are few rules to follow but many guidelines. Go with how you feel your team will have more freedom to work on the product itself. As the product grows, as the traffic and usage patterns start to appear, you will have plenty of data and metrics to base your decisions on.

A PaaS can take you a long way, an IaaS will take you to the same place and beyond but will require more hands on.

The call is yours and your team's based on where you all want to go.

Fancy talking more on this topic ? Contact me to discuss how I can help your team establish or refresh a PaaS or IaaS hosting solution.