Update: The folks from spacelift wrote an article of similar nature. Feel free to explore this to get even more value.
Buzzwords are everywhere. You may have noticed that I am not a big fan of them. They are used everywhere (sometimes in a wrong fashion) and because of that, most people afraid to ask the 101-questions as they don’t want to sound ignorant.
Some years ago, my back-then-manager asked me if I wanted to do some devops work as part of my software engineer job. Of course, I was young and afraid (for the above reasons) to ask so I just said “yeah, let’s give it a try. Worst case I will die and you will take a day off to grief”.
Thank God, I am still alive, torturing people with my writings. So now I want to give you a nice and round overview of the terms I encountered in my initial steps and wish I knew back then, plus some more that were not invented but it is good to know them now.
Let's start
Devops
The devops discipline was created to bridge the gap between the developers and the operation guys (eg IT, system engineers, DBAs etc). The main vision is to (mostly) make the transition from the development environments to the testing/production environments flawless, quick, automated and completely transparent.
Before that, the deployments were causing a constant pillow fight and nerf-shooting wars (sometimes even keyboard throwing) between the two “tribes” and the deployments were slow, painful and required lots of working hours. You can verify that easily if you are aware of a software company that doesn’t employ such practices.
The movement was influenced by the increase in popularity of Agile methodologies, as you can imagine, where fast deployments are highly encouraged and are the norm when talking about serious software companies.
IaaS
Infrastructure as a service. You are given the ability to launch a VM with an OS of your choice (well, the cloud provider has to support it, but most known Windows and Linux flavors are there ), specs of your choice (RAM, persistent storage, number of CPUs etc).
As with all stripped-down VMs, you have to set up everything yourself, with the tradeoff of being more in control.
The most known examples are EC2 from AWS, Google compute engine from Google Cloud.
PaaS
Platform as a Service. You can think of it as an abstraction of IaaS.
Everything apart from your business logic and the database part is a black box to you. You might know details about the infrastructure but you have very little control over it.
For example, you might be able to change the versions of the software you use, but this will happen:
- From the vendor’s UI
- The version modification will happen in the range the vendor supports. If the vendor doesn’t support python 3.7, you can’t have it and if you try and update manually, it most probably is painful and there is a strong chance you will screw everything. At least, that’s my experience.
The most known examples are ElasticBeanStalk from AWS, Google AppEngine from Google Cloud.
Note : there is a combination of the *aaS components in real-world cases. PaaS and IaaS working together, are especially common. This is called hybrid cloud.
Saas
Software as a Service. In that case, you want to access a piece of software (cloud-based) and you pay according to the use you do (if there are no free plans).
You have no control over the software, apart from what the UI and a potential API allows. The most known examples are Netflix, Dropbox and most of the Google services.
You can see a visual comparision of IaaS, Saas and PaaS in this article.
Provisioning
Provisioning, in the devops context, means to (automatically) bootstrap the infrastructure.
So if someone wants to provision a test environment, then he probably has to set up a few VMs (not random VMs, a specific type of VM or a certain image that is used as a template) and then set up the software required, setup any web servers etc. Sounds boring, huh?
It totally is, that’s why people are using provisioning tools that do the job for them automatically (so that they can browse Reddit and 9gag with no guilt while waiting).
Two of the most beknown tools for provisioning are Ansible and Terraform. I won’t go into details for now, as this will require a 5-times longer article, but I will show an example in Terraform to show you how straightforward it is.
resource “aws\_instance” “example” {
ami = “ami-b374d5a5”
instance\_type = “t2.micro”
provisioner “local-exec” {
command = “echo ${aws\_instance.example.public\_ip} > ip\_address.txt”
}
}
A short explanation might be required for the example above; ami stands from Amazon Image and is pretty much a VM template.
t2.micro refers to the computational features of a machine (CPU, RAM etc). If you haven’t seen this before and you are curious, you can check out this page.
Pretty much it setups a t2.micro instance with the predefined ami and when up runs the echo command, in the local-exec section.
Ansible plays at a lower level, where you define a setup of commands, called playbook, with more detailed commands. There are great articles around, like this one, I would suggest you read it.
Dockerization
Dockerazition means that you need to make some certain steps to make your application work with docker.
Docker, in a nutshell, is a means of lightweight virtualization (a bit simplified, you could read more here).
You can define a docker image, by using the so-called DockerFile, which is pretty much a set of commands that build a Docker image step by step.
Here is one of the simplest docker files you could find, along with explanations. More images to start from can be found in docker hub.
Why is all this fuss about docker though? What does docker offer?
There are lots of benefits in using docker but for me the most important use cases are:
- Portable environments. I can use the exact same environment for development, for production, for staging environments, for reproducing a production issue, for making a demo to the client…and the list goes on. No more “works on my machine” excuses.
- Setup the environment in a couple of commands. This fits greatly with provisioning as can be seen in this article.
Serverless
Contrary to what the name implies, we still have servers where the backend logic runs on. What is really happening is:
When you want to execute a certain piece of code (called a function, thus this computation model sometimes is also called function as a service — FaaS) the cloud provider allocates the necessary resources (in a dynamic way) to execute it.
After the end of the execution, it releases those resources.
The functions run in various occasional triggers or run periodically in a cron-like way.
Ideally, the functions should be pure, which means they only rely on their arguments to compute a result and not on any external state (eg database), though there is no problem using an external database server or so.
The main advantages are that you only care about your business logic and that you can scale your functions in a glimpse of an eye.
If you want more insights on that, it might be specific to AWS but this article is a great read.
A pretty good video for a quick intro would be this one from Traversy Media.
CI/CD
Continuous integration and continuous delivery. The story is: Various devs work against an upcoming release or a set of parallel in-progress features. When the code is committed (usually to the main branch, though this is configurable), a set of operations run automatically and the goal is to have all the operations succeed.
Such operations would be to make sure the code compiles, to run the unit tests successfully, to ensure the test coverage is above an acceptable threshold, the docker image of the product was generated without errors, the image was deployed to a cloud environment successfully etc.
I think you can understand how important is to have continuous feedback and perform all the necessary steps without having to think about them, and worse, having to rely on your willpower to do it. Do you know many devs that like testing? I don’t :D
Conclusion
Thank you for reading this article. If you are now entering devops, it is a fascinating field. I hope this article made the ultra-basic terminology a little bit clearer. As always, feel free to comment on any feedback you may have.
Originally published at https://perigk.github.io/.
Top comments (2)
Great article.
Thanks Joe :)