In the startup world, there is a balancing act when it comes to where you invest your time. I’ve been in many situations where, due to the need to ship an MVP, DevOps practices take a backseat.
I consider this to be normal and not really a bad thing because “MVP” should be “Minimal” , and most problems that are solved by good DevOps are not problems at such a small scale.
But here are a few things that should definitely be done (or at least considered). Because there aren’t many things worse in the startup world than having your cloud infrastructure go down.
This is a must for any startup that cares about having persistent data. You need to be automatically backing up your critical data or you risk losing more than just files, you also will lose customer trust which will impact your future growth.
I generally automate two types of backup methods when starting projects
This generally takes the form of a scheduled script, like a cron job which runs every night and pushes a database dump somewhere on the cloud like a private S3 bucket. You can have more fancy solutions with some backup solutions but those tend to be more enterprise focused and will cost you a lot of time and money (not startup friendly) .
When all else fails, if you have a copy of your disk you are generally going to be safe. Most major cloud providers have solutions in place that let you take disk snapshots on a schedule of your choosing, so try and avoid writing scripts that connect directly to the cloud api since you will be responsible for maintaining them.
Will you know when a server goes down or an app crashes due to running out of disk space? If not, you should consider fixing that problem (it doesn’t take too much time).
The simplest way to set up monitoring would usually be a cloud provider solution like Amazon CloudWatch or GCP Stackdriver. You can set up metrics to monitor and have different kinds of alerts in response to those events occurring within your cloud infrastructure, for example getting an email when your disk is running low.
If you don’t want to go with a provdier’s solution — there are cloud agnostic options too that can monitor your cloud. Simple solutions exist such as scheduling shell scripts that send emails to run periodically, but a more comprehensive solution that gives you a dashboard view of your system is generally better and much more scalable. Options like Blue Medora and Solar Winds exist for enterprise private cloud but most startups need to save money, meaning turning to open source solutions such as Countly.
All in all, I would recommend going with a cloud provider based solution as those are going to be guaranteed stable, easy to set up, and, at a startup’s scale are not going to cost you much extra.
One of the common struggles I see with startups is the process of releasing code. Many haven’t yet put the time into DevOps to develop a stable release pipeline, meaning that the code that gets pushed to version control is either manually tested, built, and released, which is both error prone as well as time consuming for your development team.
The point of continuous integration is to have a pipeline that gets kicked off every time code is ready to be committed.
Continuous deployment starts after your continuous integration pipeline has done its job of validating new code wont break your build. This generally consists of creating a new production build just like what was done in the continuous integration stage and replacing the old build (Immutable infrastructure).
Technically, you can have continuous deployment without continuous integration, but the risks of doing so are great. You would basically be pushing untested code directly to customers (🚨BAD🚨)
It’s no secret, most developers do not enjoy writing tests. They tend to need constant updating as applications evolve and are a large time sink, so naturally many startups will neglect writing tests because “MVP”.
If you don’t have a comprehensive test suite I would not bother thinking about CI/CD until this is remedied. As the testing coverage improves you will start to see major efficiency gains as you see less and less bugs in production. This is the point when you should move on to the other pieces of your CI/CD pipeline.
Don’t be afraid of containers, while the technology itself is complex and hard to understand without a fundamental knowledge of kernals, taking advantage of them and converting apps to containers is really quite trivial.
It usually takes less than an hour to put together a Dockerfile (depending on your app’s complexity) and before you know it, you can deploy your app instantly and take advantage of great systems such as Kubernetes.
Here are some benefits you can gain immediately by containerizing your application.
No more “it works on my machine” problems — If the container builds, it will run on any machine the same way.
You know how when you want to set up an open-source project you have to go through all kinds of manual steps, setting up databases and installing package that are required? With containers this is no longer the case, all those steps are baked into the build process and all you need to do is run a single command to start up your servers.
Container platforms like Docker and Kubernetes have a very large and growing ecosystem of products and services to help you manage your applications easier. A lot of headache around things like storage, networking, and resource allocation are basically eliminated saving you time and money.
Many startups don’t put much thought or time into their cloud infrastructure. This is generally due to MVP philosophy of shipping first and cleaning up technical debt afterwards.
When looking to scale up your DevOps infrastructure — consider scheduled backups, monitoring, CI/CD and containerization. These are generally easy wins and will lead to a much more stable cloud.