The goal and driver of many tools is reduced complexity. There are many IT as a Service products that claim they reduce complexity—but is that what they really do? IT has gotten inherently complex, yet we are claiming to reduce complexity by adding in more layers, such as automation, platforms, containers, etc. Do these technologies really reduce complexity? Or do they hide complexity?
Here is a short history of technology:
- We carried items in our hands
- So we created baskets by weaving reeds together to help us carry items
- Then, we added wheels to our baskets, with an axle and pins to hold the wheels to the axle
- We added a horse to the cart with harness, reins, hitch, and excrement catcher
- We took away the horse and added an engine (pistons, gauges, tubes, radiators), drive train, fuel tanks, steering controls, and exhaust
- We added stylish exteriors, more seats, wider wheels, steel rims, more gauges, better steering, etc.
- We added computers to our vehicles to increase gas mileage and performance, and to monitor everything, which led to more gauges and more sensors
- We added big data to collect all the sensor data; initial analytics was threshold based
- We changed our analytics to machine learning, to handle even more data
- We moved to artificial intelligence, taught computers to recognize images, and now have self-driving cars that gather even more data
Well, as you can see, the simple wheel led to one of the most complex technologies we have today: self-driving cars. Yet, along the way, we kept adding complexity. At no time did we go back to merely the simple “we carry things in our hands.” Our time-saving techniques save time, but they make things more complex. The perception is that things are easier and less complex. The reality is much different.
In order to fix a car, for example, we need to take it to a mechanic who has the knowledge to fix what is wrong. A mechanic is part of a specialized group of people with specialized training. If AI breaks, we need the tools and knowledge to fix the problem. With vehicles, the matter could be life or death; with other business data, it could be the health of the organization that is at risk. As complexity grows, risk also grows. Keeping us safe from that risk is the job of many folks who have the specialized skill to fix problems that occur.
Many folks seem to believe that adding containers reduces complexity—yet, in reality, it adds complexity. We need to always ask ourselves the simple question:
Can you fix it if it breaks?
If you cannot fix the issue if it breaks, then you need to find the folks who know how to do this. If you are in a cloud, that list is short, and it has a very big demarcation. The split is between what happens within your machine instance and what happens outside. Outside is often the cloud; inside is the organization’s responsibility. Within an on-site data center, everything is the organization’s responsibility. Knowledge of the underlying levels can help solve problems inside your machine instance regardless of where it lives, whether in the cloud or on-site.
As we talk about cloud and on-site, we often need to talk about data. That can be summed up in one question as well:
Do you know where your data resides and are you satisfied with your backup?
In reality it is two questions, but they are related. Knowledge of your data and data protection go hand in hand. If you do not know where your data resides, you cannot protect it. This itself adds complexity to any effort.
As you can see, perceived reduction of complexity is not the reduction of actual complexity. You need to think about all those things abstracted away that actually do have problems from time to time—hopefully, less often than before.