Common Mistakes Startups Make When Managing their Cloud
This article is based on a collection of experiences from working as a DevOps Engineer for 5 years in Sydney, Australia.
Managing servers and databases manually
SSH to a server to install or update a package. Write cron scripts to backup your database.
Do these activities sound familiar? They are common practice, unfortunately, but will cause the following issues:
- lack of consistency
- reliance on individuals
- configuration drift
It’s simple to avoid this pattern:
- Use a database service (e.g. AWS RDS, Google CloudSQL).
- Build and deploy with a container platform (AWS ECS, Kubernetes).
Not using cloud services (SaaS)
Startups really shouldn’t be deploying their own Atlassian stack inside their cloud. The same goes for logging and monitoring tools, etc.
Maintaining those services can be:
- expensive (labour, infrastructure and licence costs)
- prone to downtime
The only exception is when there are compliance requirements that force some data to be hosted in a controlled environment. Even in these cases, it’s always good to check if the SaaS provider can comply with the terms before deploying a product in-house.
Always shop around for a SaaS vendor that provides the tool or service you need. Some examples:
- Sumologic, Logentries, Cloudwatch, Elastic instead of your own ELK stack
- Atlassian Cloud
- Gitlab or Github
Having only one environment: Production
It’s common for startups to “hack” something together with some code, ssh to an EC2 or Droplet, install dependencies, git clone and that’s it, it’s live.
Once users start to come and you need to deliver new features, how can you be sure it’s not going to break?
Firstly, you need to make sure automation is in place and code is being deployed with a Continuous Integration (CI) pipeline.
Then, the beauty of automation is that it doesn’t care if you deploy to one environment or 10.
The bottom line: Always have one or more non-production environments that are identical to production. This way you can deploy and test your code before it reaches your users.
Not having a CI/CD pipeline
A Continuous Integration / Continuous Deployment (CI/CD) pipeline is what makes the automation and frictionless deployment work. Having code built, tested and deployed through a pipeline brings many benefits, such as:
- visibility on what’s deployed
- “single source of truth” for building, testing and deploying your code
- more deliveries and features reach your users faster
Make sure the tool you choose supports pipeline-as-code and start right from the beginning.
Not caring about security
Unfortunately, it is still very common for startups to overlook security until something happens.
Implementing security policies later can affect your team’s productivity and sometimes even cause downtime, so it’s better to start with something in place.
Recommendations:
- Create security boundaries (per AWS account, for example), so policies are simpler and easier to maintain.
- In customer-facing (production) environments, set least-access policies, starting with the bare minimum and adding access as it’s necessary.
- Any changes in production environments must be made by using infrastructure-as-code, tested in non-production and peer-reviewed before deploying.
- Make sure firewalls (security groups) allow only granular access to the services, never with a rule allowing the whole network or all ports.
- Make sure code is peer-reviewed before going to production — this can be enforced by setting branch permissions in your GIT repository to only allow merging a pull request to the master branch with multiple approvals.
Not applying for credits
Most public clouds have credits program for startups. Some are:
- AWS Activate (https://aws.amazon.com/activate/)
Up to $100K - Microsoft for Startups — Azure (https://startups.microsoft.com/en-us/benefits/)
Up to 120K for 2 years - Google Cloud (https://cloud.google.com/developers/startups/)
Up to $100K for 1 year
If your startup is part of an accelerator, incubator or even co-working space, check with them. It’s very likely they have a partnership with one or more cloud providers.
Conclusion
Hopefully, this article was helpful in some way.
Please leave your feedback below as well as anything you would like to see added.
We work at DNX Solutions and help to bring a better cloud and application experience for digital native startups in Australia.
Our current focus areas are: AWS, Well-Architected Solutions, Containers, ECS, Kubernetes, Continuous Integration/Continuous Delivery and recently service mesh.
We are constantly hiring cloud engineers for our Sydney office, focusing on cloud-native concepts.
Check our open source projects at https://github.com/DNXLabs and follow us on our Twitter or Linkedin
