Big Confusing Mess
Getting screwed by too much “glue” and too many dependencies in your homegrown hosting platform
How the mess begins
There are about a million different ways to put your code in to production. From PaaS providers like Heroku and AppEngine, doing it yourself with VPS providers like DigitalOcean and Linode, using tools provided by AWS or Google, or one of a boat-load of other solutions.
Most (smart) businesses have a few goals when it comes to running their hosting infrastructure:
- Avoid downtime at all costs
- Make sure the site or application is fast and responsive
- Remain cost effective
- Stay flexible and avoid getting trapped in a solution or provider that won’t work in 6 months
- Promote systems automation to increase efficiency and ability to scale quickly to meet demand
With these goals in mind, engineering sets out on a mission to find the best solution that will meet all the criteria. They will probably be thinking:
- Should we marry ourselves to a hosting provider and use their tools?
- Do we chase the dream and try to be hosting provider agnostic?
In many cases it’s not easy to find a silver bullet, the fear of lock-in is too great, and they settle on building their own solution using a mashup of many open source tools, and a few from their provider. Maybe they start out finding a way to automatically launch virtual machine instances with Terraform or CloudFormation, then they choose Chef or Puppet for configuration management, and then figure out how to integrate them together using custom User Data scripts.
After a long period of writing configuration management code, tweaking it just right for their environment, and finding out that Chef is pretty damn complicated, they finally put their new system in to production.
At this point things are looking pretty good and may even be working well, but as business needs change and the customer footprint grows, they will need to come up with solutions to new problems that require new tools, and complicate the environment.
Being Provider Agnostic is Difficult
To be truly provider agnostic, there are a lot of systems you need to implement and master. This will quickly increase the complexity of your environment and the number of moving parts you need to keep track of. Below I have listed some of the areas where you will need to implement your own solution to be fully provider agnostic, and some examples of each.
- Monitoring and alerting (Sensu, Nagios, Zabbix, Zenoss)
- Graphing and metrics (Graphite, InfluxDB, Grafana, MRTG)
- Logging (Rsyslog, Logstash, ElasticSearch, Kibana, Greylog)
- Load Balancing (Nginx, HaProxy, LVS)
Each of these tools is something new that each member of your engineering team will need to learn how to operate, maintain, and fix in the event of a problem. Suddenly the job requirements for a new hire are longer than the menu at Cheesecake Factory.
Get the Elmer’s out, this isn’t going to be fun.
The Rise of Containers Exacerbates the Problem
Containers are all the rage. They make development workflows easier. They make immutable deployments an achievable reality. They make it easier to pack more onto your existing hardware.
Despite that, containers are still going to make your life more complicated. That is especially true when you are a provider agnostic open source ninja.
You’ve decided that containers like Docker are the way forward for your hosting infrastructure, now you just need to pick some tools and get to work! But what tools do you need to actually make it all work? Well… you need many.
- A cluster scheduler
- Some kind of init system for the cluster
- Service discovery so that your apps can find each other
- A cluster DNS system that stays up to date as containers are moved or restarted
- A way to handle applications with persistent data needs, like databases.
- Load balancing that sends traffic to the right place
- A build and continuous integration pipeline
- A Docker image registry
- Monitoring for every part of the system
Now you’ve taken your already complicated hosting platform and loaded an entirely new layer on top. The length of that operations engineer job posting is starting to look a bit ridiculous.
The worst part about all of this is that currently each of the components above is provided by a different startup. All of them have their own agenda, and leave it up to you to create the glue needed to plug everything together. Get the Elmer’s out, this isn’t going to be fun.
The Questions You Need to Ask Yourself
- Who on the team owns and maintains which components of the infrastructure?
- How do we train new members on the team, and how well is our “glue” documented?
- How far down the customization rabbit hole do we want to go?
- Will these components always work together?
- What is the game plan if they suddenly stop working together?
- Is our business dedicated to long term maintenance of our customized setup?
- What happens when the people who created our “glue” leave the company?
- Where do we turn for support in the event of a major problem?
- How hard will it be to identify the source of an issue in this system that contains many layers?
It’s important to consider if you are ready to deal with these inevitable issues before you embark on implementing a hosting platform consisting of a hodge podge of open source projects.
An Alternative Solution
The good news is that there is an alternative solution that is open source and also provides all of the components you need to have a fully functioning hosting platform that runs Docker containers.
ContainerShip makes it so that you won’t need to write any glue code. All of the components are provided and work together seamlessly, and you will be able to get help from support in the event of a problem.
Best of all, you can completely ditch all the work of manually setting up the environment yourself. Using ContainerShip Cloud, all you need to do is connect your hosting provider, click a few buttons and select a few settings, and the whole things gets stood up on your hardware in minutes. You also get the safety net of point in time backups, so if everything comes crashing down in the middle of the night, restoring is as easy as a few button clicks.
ContainerShip is always free and open source, and ContainerShip Cloud is completely free during our beta period.
Learn more about ContainerShip:
