As an IT service management (ITSM) professional you might be at arm’s length from what’s happening in the software development world. You appreciate that there’s a lot of change and innovation happening but when it gets talked about you might not necessarily understand everything that’s being said. Of course, you could rely on Google’s fantastic brain to fill your knowledge gaps or, alternatively, you can read this blog to quickly understand more about three of the hot technology buzzwords being used in 2017.
As if the IT industry doesn’t already have enough acronyms and buzzwords, yet more continue to fall from the lips of industry pundits and bleeding-edge technology practitioners. This blog explores three IT industry buzzwords, plucked from the froth on the top of industry minds, which have been chosen because they seem to be constantly talked about and are all related:
- Continuous integration/continuous delivery (CI/CD)
So, what’s the heat behind the buzz in these words?
1. Continuous Integration/Continuous Delivery
Consider a woodsman feeding logs (the code) into a wood chipper (the code pipeline), then continuous integration is the automatic chipping mechanism and continuous delivery is the automatic spraying of wood chips into a neat pile. Quick and reliably, continuously chipped and sprayed.
Continuous integration is what happens with DevOps after a developer checks-in/commits code to a version control system such as the ubiquitous GitHub. This check-in/commit is detected by the CI/CD system and the code is automagically compiled, built, and tested – that is, integrated. Then another check-in/commit, another automagical build – that is, continuously.
Continuous delivery is the whole pipeline from code check-in to production deployment. After continuous integration, there are the staging and production deploys. The goal of continuous delivery is to do the opposite of traditional change management. Instead of bottling up lots of changes into one big release, continuous delivery prefers one change per release. So if you have lots of changes, then you have lots of releases.
This can be visualized via my good friend Stevie Chambers’ diagram below:
Source: Steve Chambers
Microservices refers to a software architecture where small programs – that do one thing well – work in unison to form an application and deliver a service. Think of your online banking application that provides lots of services to you – paying bills, transferring money, checking balances, etc. Each of those services could be implemented as individual programs in a microservices architecture.
If your bank has implemented their app as one big Java program running on one big server somewhere, then that’s the opposite of microservices and it’s called “monolithic.” Monolithic isn’t by default bad, but the problem with monolithic programs is that they can have tens, if not hundreds, of services coded inside them. This is a problem because the bank has to release a whole new big program just to update one embedded service. Which means full system downtime for one thing, but it also means the blast radius of change mistakes are potentially the whole application. Plus, if inside that monolithic Java program, services call each other, then you have a hidden spaghetti of dependencies.
However, your bank might have implemented their online application as microservices. They might still be using Java as the programming language but, instead of one big program on one big server, they have lots of small programs distributed across lots of small servers. Each program does one thing well. If you want to update “Checking Balances” then you just touch that single microservice – everything else is untouched and keeps running.
Source: Martin Fowler, Microservices
The size of a microservice is not measured in lines of code, but rather how many things it does. And the industry direction for that number is one. They are already being used in industry, as technology expert Martin Fowler points out: Netflix, eBay, Amazon, the UK Government Digital Service, realestate.com.au, Forward, Twitter, PayPal, Gilt, Bluemix, Soundcloud, The Guardian, and many other large-scale websites and applications have all evolved from monolithic to microservices architecture.
There are few tech-industry buzzwords that have triggered as much fanfare and despair in equal quantities as “serverless” has. The fans might just have shaded the haters, though: how many buzzwords get their own conference so quickly? There are three important things to know and understand about serverless.
Firstly, serverless was initially chosen as a name because it describes, from the developer’s point of view, that they don’t have to manage servers. Yes, their code runs on a server somewhere, but the point is that the server is not the developer’s concern. The cloud service provider is taking care of the servers, doing all the networking and all that famously undifferentiated heavy lifting. The developer is freed from patching, logging, and all the other mundane yet must-do infrastructure activities. For this reason, serverless is sometimes described as “NoOps” or “AppOps”, but this just gets the haters more heated.
Secondly, the developer “does serverless” by uploading their code in the form of a “function” into the cloud. This is why serverless is also known as Functions-as-a-Service (FaaS – yay! Another cloud aaS acronym!). Once the code is uploaded, the developer tells the cloud service how to run it – which security credentials, which variables, which language version, and which events trigger the function.
This last point, event triggering, is perhaps the most important part of serverless (even though it appears nowhere in the name). An example is when a message arrives in a queue, or an object is put in a storage bucket, and these triggering events cause your function to be run.
“Event-driven NoOps serverless Functions-as-a-Service” might be a more accurate title, but it’s a mouthful compared to just serverless, wouldn’t you say? Oh, and you can read more on serverless here.
So that’s three hot technology buzzwords explained. What else are you hearing about that needs blogging about? Please let me know in the comments.