The days that having computing power equals buying computers is becoming more and more a distant memory. With these in-house-computers you needed support engineers to setup and maintain them. Amazon’s Cloud proposition has changed all this by making a pay per use model possible. You only pay for what you use, not what you own. On the software-side we saw the advent of a number of tools for configuration and provisioning of systems turning manual and time-consuming labor into one simple click. These tools enabled something we call DevOps, In practical terms: a software engineering culture and practice that aims at unifying software development and software operation… But this ongoing automation has an impact on the support engineer who sees his job is in jeopardy. What is the future of the support engineers? In this blog, I will share my vision and would love to hear yours too.
Back to the past
Let’s backtrack a bit to see where we came from as far as the more technical side of IT. Don’t worry, we are not going to the ENIAC to where we are now, just the high-level overview. It is true to say that we have actually continued the path that started with the ENIAC (shown above) and progressively worked on improving the performance of CPU’s and as a result a general increase of overall computing power. The ENIAC is now outperformed by any smartphone or perhaps even an advanced calculator. In 1981, the first IBM PC’s with the 8088 chip and 256K ram and a floppy drive for storage was found. A big step forward with the PC becoming a product for use by many people. In the following years, thanks to Moore’s law, we saw increases in computing power going all the way to where we are now: a laptop computer with easily 8GB of memory and a quad core processor enabling multi-tasking in a graphical environment. Around 2006, Amazon (re)started with the first cloud services called AWS. It was a paradigm shift because we now had the opportunity to see computing separate from hardware. Until that time, computing was tied to hardware (largely). Universities and research centers pooled their computing power into Grid computing but Amazon went beyond that by deploying a model that not only decoupled usage from ownership but also made it easy to quickly start computing resources.
The shift from DevOps to NoOps
Another ten to twelve years later we are where we currently are, in 2018. AWS, Amazon’s cloud offering, is now part of many organizations IT infrastructure. On the other hand, I see a flurry of tools enabling infrastructure as code which enables you to create scripts that will setup and provision your environment in a repeatable and controllable manner. Therefor management and deployment becomes much easier and allows one person to do everything. But why do we want to go to NoOps: No Operations, everything with the press of a button? To some extent it’s all about optimization of processes. DevOps goal is to get shorter development cycles, releasing more versions more frequently, making quality more dependable, aligning with business demands. NoOps takes all of the improvements in the area of cloud, provisioning, configuration and deployment and abstracts all of that for the NoOps guy or girl (yes, we should have more women in IT). This results in plug-and-play applications that are ready to use, without the interference of support engineers. But can it really be that simple? Are we there yet or is this wishful thinking?
Building applications is like ordering food
The big cloud providers like Google and Amazon and new kid on the block Oracle are pushing hard to sell their X-as-a-Service (X can be a platform, infrastructure, or an application). The deployment of these services used to be a job for technical people exclusively, but today, “normal business people” can do the same with one press of a button: NoOps. They simply press “play” and they can have applications up and running. They don’t have to think about back up, compute power, networking, and so on. Like you’re ordering food or clothes. Of course, there is a lot going on behind the scenes. Setting up an environment for NoOps is an art of its own and should be part of your IT strategy. Because NoOps is the natural way forward, making IT easier for everyone. NoOps is also almost a prerequisite for going digital. Because going digital means shorter turnaround times for many if not all your processes. Going digital starts with taking your processes and adding digitization to it. But that is just level one, the easy stuff. Level two is optimizing the processes to take advantage of the possibilities. The holy grail is level three: Digital Imagination. What new things or products or services can we imagine for the future? If you do not already have a digital strategy my best advice would be to get one (they are great!). Your competitors are going digital as well, your stakeholders or shareholders expect lean and mean operations and your customers want more and better service.
The future of the support engineer
Having said all above the questions is: will we need support engineers in 10-15 years’ time? I don’t think so. When the abstraction continues and the ease of use increases, the workload will shift. Obviously, when tools will do the work, people do not need to do it. Manually provisioning an infrastructure that takes hours and are prone to error will be replaced by a press of a button and almost instant results. Of course, we need to setup these scripts but after that it is a case of Ready – Set – Go. But what will we do with our support engineers? Is there a job for them? Since we have a chronic demand for skilled employees in IT we see an exciting future for support engineers. The need for integration and APIs will increase, though, and enormously. Business have a range of applications from social media, to Saas Systems that they want to integrate with another. They don’t care about computer power: they only want things to communicate, as smoothly as possible. Integration remains a craftsmanship that’s needed in the future. Integration is also a people’s job.
With all of the benefits of NoOps, either as standalone goal or as part of an ongoing Going Digital strategy, for me it’s clear: support engineers should become integration experts. . Integration remains a craft that’s needed in the future. Integration is also a people’s job.Support engineers already have the technical knowledge that we want our people to have and for a Support Engineer it should be easy to jump into another exiting role. The time to look into NoOps is now. Within that transition, your support engineers have to be part of that movement as (future) integration experts. And if needed, you’ll book a seat at one of our trainings to get them trained :-).
Going digital is a journey and a journey is best taken with planning and guidance. Read our white paper with regards to Going Digital. It will offer you insight into the steps you need to take and the issues you need to consider. And remember, you can always count on us for help. Go from pushing many buttons to pressing just ‘one button’. That is progress!