Six Tech Buzzwords and What They Actually Mean
If you’re trying to break into tech, one of the biggest issues you are probably facing is all these new buzzwords you are encountering every day. Every article you read mentions at least one of them, every Udemy course you take strongly suggests you get comfortable with them etc.
Some are currently still just buzzwords, some have in fact, become industry standards. I’d like to talk about 6 of these buzzwords and discuss whether they really should be your focus.
- Serverless
The age of cloud computing is upon us (cloud — yet another word you’re probably hearing all of the time). One of it’s most significant accomplishments is making the deployment of web applications as easy as possible. The modus operandi is of the cloud is simple to explain : for an arguably reasonable price, you can delegate many crucial aspects of your application’s infrastructure to a cloud provider, so that you can focus on business logic, and worry less about the application being available to it’s users. There are however, many different levels of responsibility you can delegate. You can simply rent servers (virtual machines) for a fixed amount of time, and worry about everything else yourself (like patching the software running on those machines). You can also rent the servers, plus the software running on them, thus relieving yourself of one more worry. Finally, you can rent the servers only when there’s actually work being done on those servers, so that if part of your application has idle time, you won’t get charged. This is basically what serverless means. The cloud provider is saying — give us your code, and some event that will trigger it (like an http request, or a file upload) and we will guarantee that the code will run only then, so your bill will probably be a lot lower than if you rented an entire server to do that job. Also, if your app sees increased traffic, let us handle the horizontal scaling and availability. Serverless doesn’t mean that magically there are no servers, it just means that the servers are somewhere in the cloud, and you do not have to worry the least bit about maintenance.
The rise of serverless is happening as we speak, however, it will still probably take years before it becomes the default model for deploying applications, especially complex enterprise apps.
If you want to explore serveless more, take a look at technologies like AWS SAM, API Gateway/Lambda/DynamoDb and Google Cloud Run.
2. Devops
There really isn’t a definition of devops that all parties agree upon. It can loosely be defined as a methodology for developing software. The dominant methodology currently. The idea is that software updates should be deployed daily and smoothly. How? By implementing devops best practices. Continuous integration, continuous deployment, test automation, agile — these are all components (and buzzwords for themselves) of the devops philosophy. Software development has become the most lucrative of businesses, with companies being valuated at trillions of dollars, and it was about time that some best practices were defined.
Devops has a lot to do with the cloud also, because provisioning infrastructure has become cheap and widely available thanks to the cloud. This means that the cloud and devops go hand in hand. Running automated tests is another major aspect of devops. Like any widely used product, software has to be tested continuously and extensively. Since computers are far more efficient than humans, it only makes sense to delegate these tests to them.
The CICD pipeline, which is the cornerstone of devops, is based on the cycle of continuously planning, building, testing ,deploying software updates to production, and monitoring their behavior afterwards. The actual pipeline (which is usually nothing more than a YAML file or Groovy script) is responsible for running the builds, tests and deployments, while the developer is responsible for writing the code, and the QA for writing the tests.
What is the role of the devops engineer then? I would say everything else. From maintaining the pipeline, provisioning cloud infrastructure, ensuring the application is up, monitoring and patching.
Some companies call devops engineers “Site reliability engineers” because the term devops is too broad. Other companies just call them “ops people”. Like I said, devops is more of a methodology, or even philosophy, than it is a position.
I personally think it is very efficient, and that it is going to continue being the default way of developing and deploying software.
If you want to be good at devops, I would suggest a number of technologies. Start with Linux (over 95% of all servers run it). Try a CICD tool like Jenkins. Learn about containers (Docker especially, then gradually learn about Kubernetes). There’s much more, but those are some good starting points.
3. Microservices
Since we’re talking about cloud and devops, it is only fair to mention microservices. These 3 are like the holy trinity of modern software development. If the cloud is where your software lives, and devops is the methodology used for it’s creation and deployment, then microservices is the structure or form of what is actually being built.
More simply put — you build your application as a collection of smaller applications (microservices) in a continuously built and tested way (devops) and deploy them to someone else’s computers that you can rent cheap (the cloud) . You package these microservices in containers (another buzzword) so that they are resilient to any environmental changes.
Although monolithic applications still exist (and are still widely popular) , the microservices architecture is slowly becoming the industry standard, especially for enterprise apps. The term “cloud native application” (yet another buzzword) is practically synonymous with it. The reason is, if you’re going to choose a microservice architecture for your app, it only makes sense that you deploy it to the cloud, where your various services can easily scale when needed and communicate with each other over secure and highly available networks.
The main benefit of microservices is loose coupling of application components, meaning if one part of your app fails (which happens all the time) , the other pieces continue to work, so users are not entirely deprived of your services. Another benefit is reduced team sizes. Instead of having a massive team with dozens of engineers working all on the same code base, you now have dozens of teams of just several engineers, and they can work on that part of the application in any language/framework that best fits the requirements and capabilities of the team.
The drawbacks are also large, however. Because of the distributed nature of the application, most of the simple function calls are now network calls which can cause latency and even failure due to network issues.
It’s really a trade off, and many smaller applications are much better off using the traditional monolithic approach. Large enterprise applications, on the other hand, are massively adopting the microservices pattern.
4. Artificial Intelligence
Let’s take a breather from the whole devops/cloud/microservices madness and look at another term that is used daily. AI is highly connected to other buzzwords like Machine Learning, Big Data, Computer Vision, Natural Language Processing and, of course, Data Science.
The massive popularity of AI is due to the fact that CPUs/GPUs are now fast and cheap, and able to process and statistically analyze huge amounts of data in very short periods of time. Statistically is really the keyword for me here. The advancements of AI are all based on statistical inferences, that have actually been used for a long time. The main difference is, that the speed of processing data has grown exponentially since Fisher, Bayes and the other fathers of statistics were in their prime.
The fact that computers are now able to understand human language and even interpret images is all based on probability theory and cheap computing power (which you can find and rent even cheaper on the cloud by the way). The most worrying part of AI for me is the ethics behind it, or rather for what goals will this incredible power be used. Some are extremely noble, like analyzing medical data in order to diagnose diseases with great speed and precision. Other goals are not quite so noble, and the abuse of AI (and the large amounts of data it feeds on) is perhaps a reason for the rise of buzzword number 6 (encore creepy music).
5. Big Data
For AI to do it’s magic, it needs data. A lot of it. Big data is defined with the three Vs — Volume, Velocity, Variety, meaning there has to be a large amount of it, it is produced rapidly and collected in real time, and it is of various formats.
The misconception behind Data Science and Machine Learning is that it all boils down to selecting the proper model by which we gain valuable insights and make accurate predictions. Although that part does require expert knowledge (both in mathematics/statistics and also in the domain being explored), the largest part of the job is actually collecting the data, cleaning it and preparing it for modeling. That part is usually termed — data engineering. The data engineering pipeline consists of ETL — extract, transform and load. Although this sounds relatively straight forward it can easily turn into a nightmare. When you consider the huge volume of data, the number of potential errors while collecting, processing it and storing it in a durable data store can also be huge.
Once again, cloud to the rescue. Although the source of your data can be literally anything, the applications collecting and transforming that data will probably be running on the cloud, and the durable data store will most definitely be on the cloud, either in a data warehouse or in a data lake (which isn’t a lake really, it’s just a bunch of different files on something like AWS S3).
For working with big data there are many different frameworks. Hadoop was the first really popular one, but lately Spark has become more widely adopted. In order to take advantage of the distributed nature of these big data frameworks, you could definitely use a lot of computers. Better yet, you could rent out other people’s computers cheap (see where I’m getting at).
6. Web 3
This one has become all the fuss lately on platforms like Tech Twitter (which is a colloquial term for a bunch of Twitter accounts that post tweets mostly about JavaScript) . It mainly revolves around blockchain (yes, another buzzword) . The idea is that Web 2 (which is the web we use now) is becoming increasingly centralized and our privacy is constantly being compromised by large tech enterprises like Facebook and Google who get rich by selling our data. Although this is mostly true, the sustainability of the alternative being proposed by Web 3 enthusiasts is still yet to be proven. Web 3 is all about decentralization, however it turns out a lot of these dapps (decentralized applications) are being deployed on major cloud providers like AWS (which is the textbook example of centralization). Another massive phenomenon of Web 3 is the increasing amount of crypto currencies, some of which have valuations larger than GDPs of some very developed countries. Will crypto take over as a mainstream payment solution, or will it blow up in the next great bubble — we will have to wait and see.
One thing is certain, this movement is definitely becoming a force to be reckoned with, and the motive behind it does have a certain nobility. The main worry, is how the actual implementation will look, if it does indeed become an industry standard. In some way it is like a digital Marxism — the main idea behind it is noble (power to the people) , but the implementation can be anything but. Especially considering the large number of scams out there.
I guess for this one we just have to wait and see. One of the best products of Web 3 so far is the Brave web browser (at least Web 3 enthusiasts say it is a Web 3 browser), because I can now finally browse the net without being flooded with ads :)
Hopefully this article served to better explain some of the terms that newcomers to the tech industry are constantly being bombarded with. In the end, as a newcomer, you shouldn’t worry too much about any of them. Instead, focus on the fundamentals, and keep a high level overview of these terms in your head, and worry about them when the time comes.
Thanks for reading, and if I missed anything (or if you think I wrote a ton of bs maybe 😂) please leave a comment.
