On-Premise Computing
Once upon a time, an eternity ago, people used to ship applications to servers directly. Those prehistoric humans even set up servers in their own homes! We now call this odd practice “on-premise deployment”. They would install Linux on a PC, then setup a backend application written in some archaic framework like Ruby on Rails. If they needed emails, or some place to keep their apps data, or any other auxiliary technologies - they needed to self host them as well. They would then hook up the server to a locally running NGINX or Apache instance. They even went to their ISPs to get a static IP address so their home PCs could be reachable from around the world! It took tremendous skill and understanding of operating systems, networking, servers, databases, email, and much more to be able to effectively scale these applications from pet projects to production beasts.
Clouds Emerge
Then God created clouds. I mean tech giants created cloud computing. Cloud computing is basically someone else doing all the work I described above for you - and giving you a much simpler API to achieve the same goals. Today’s world of DevOps is significantly more complex, because we need to achieve much larger scaling goals, effectively handle big data, run massive machine learning models, and much more. But the foundations are still the same, and creating a simple web application is much easier than ever before. People can rent a compute unit from AWS, GCP, Digital Ocean, and many other providers - ssh
into them, and create any app they want. However, this practice is not much different from what we used to do before cloud computing; the primary distinction being that someone else is now responsible for managing, replacing, and upgrading the hardware.
Pros and Cons
Overall, both cloud and on-premise solutions have their own advantages.
- Cost: On-premise servers often have high upfront costs due to the need for equipment, installation, and ongoing maintenance. In contrast, cloud services tend to have lower upfront pay-as-you-go costs that can spiral out of control at scale. A recent article showcased the insane savings you can have if you migrate to on-premise from the cloud.
- Scalability: While cloud servers may be more expensive at scale, at least they allow for it. Cloud services are more scalable than on-premise servers, being able to adjust quickly to changes in traffic and user demand.
- Security: While on-premise servers allow businesses to have full control over their security, reputable cloud services provide a so-called “shared responsibility model” - where the cloud provider deals with the security of the infrastructure, while the user only deals with the security of the application.
- Control: On-premise servers give businesses complete control over their data and how it’s handled. However, full responsibility also means businesses have to manage their own backups and disaster recovery.
Terraform
Most modern startups go with so called cloud-native solutions, which means their infrastructure is designed bottom-up to be run on the cloud. This is usually combined with a somewhat new practice called Infrastructure as Code. This approach mainly got popularized by HashiCorp with their Terraform project. It is the practice of using code to describe your architecture. Then you can apply the code and get back a file describing the current state of your architecture. On the next apply, Terraform will compares its description to the current state file, and change only the differences. This approach alleviates the pains of creating servers by making your infrastructure:
- Repeatable - if something breaks, you don’t have to go into the AWS console by hand and try to recreate everything as you had done last time. This is time and energy consuming, and at times almost impossible if the steps weren’t documented. Terraform is self-documenting code, and all you need to do is rerun it to get to the same state.
- Auditable - if any issues arise, you don’t need to go through many confusing tabs in your cloud provider to find out what was the intention. You can go through the Terraform code and understand what was the expected result, and only debug the parts that are relevant to the issue.
- Tracked by Git -
git blame
is the greatest tool to find and eliminate the person responsible for wasting your weekend by introducing a regression while all they wanted to do was “change the style of a button” (you know who you are). So why not make your infrastructure code also trackable by Git? - Composable - by using newer tools like CDK for Terraform, you can use your most hated languages like TypeScript, Python or Java to describe your infrastructure. This code then compiles to JSON files which can be applied to manage your infrastructure. CDKTF allows you to use high-level code to compose together related services. E.g. with one class you can create a database, an S3 bucket, a cron job to back the database up to the S3 once a day, add it to a VPC, and create all the necessary permissions for it. After this spinning up a new db with all its surrounding architecture is just one line.
- All in one place - last, but not least, using Terraform you can manage resources from different cloud providers. If you have some of your services in AWS and others in GCP - Terraform got you covered, you can manage both side by side in the same project.
Conclusion
Overall, Cloud-Native solutions are getting all the attention nowadays. On one hand it’s the profit of the companies selling them (did you know Amazon’s main business model is renting computers?), on the other is the ease of use they provide to exponentially growing startups. With the advent of technologies that make less sense in on-premise architectures like Terraform and Kubernetes, the industry shifts more and more towards cloud-native solutions, while still maintaining some healthy percentage of hybrid options as well. As these technologies continue to evolve and new ones pop up, it will be fascinating to see which new paradigms emerge in the world of DevOps to make our lives both easier and harder, but never dull.