cross-posted on medium and LinkedIn
This blog post will be the first installment of a multi-part series on technology, data, self-optimization, and context. Context is the often overlooked constant required for any level of optimization or understanding of a data-based problem.
I’ve worked in product capacities in the technology space for over ten years as a technologist and a go-to-market expert. I was taking products to the market and the market back to the product to create customer-centric solutions.
In that time I had the privilege of creating products and use cases to enhance the workflows used by tens of thousands of people every day and also creating products to create self-optimizing ecosystems. We will dive into the concept of context today to understand the importance of this often-overlooked variable in a contained system. Then look at it in other environments later. We will also talk about location and why location in many use cases is the ultimate in context.
Because this topic does come somewhat close to my day-to-day job, I should go ahead and say that this is my personal blog; the opinions are my own and may not represent my employer’s views. I hope to provoke you to look at more problems in terms of context and not just focus entirely on the data.’ Data is driven and explained by context.
We live in a connected world. That’s nothing new; digitization powers almost every single action we take in the world today. Infrastructure has gone from many data centers across tens of thousands of offices to fewer, larger ones, run by companies with significant expertise and most likely their own scale requirements. Every single operation creates a well-orchestrated ballet of storage, compute, and infrastructure. These “cloud data centers” are little self-optimizing ecosystems. Some optimize for efficiency, and some for resilience and low management overhead.
So how does a lights-out facility in Lapland self-optimize today to bring you tweets, pictures, and videos? And why is this so important?
Datacenters are inherently big consumers of resources. We can look at this from the perspective of raw materials being used to create the different pieces of hardware that go into building one, to the daily consumption of electricity by the devices, to the power needed to get rid of the excess heat created by the servers. Some companies purchase renewable energy to offset some of that environmental cost. That’s great but shouldn’t the goal be to minimize both power consumption and the subsequent extraneous costs.
Doing more with less
I’m not going to dive into conflict materials needed to create chips and servers today. Still, the rare earths used to make most of the electronic infrastructure we hold dear create pollution when being extracted, and they also tend not to be the most stable places in the world. Any electronic device already carries this legacy debt. As a result, we should look at doing more with less infrastructure.
Overprovisioning
The desire to do more with less isn’t new, and it sparked the trend to ‘software-defined infrastructure/datacenters/etc.’, a snazzy term to a level of maturity on top of virtual machines of yore. The concept allows ‘over-provisioning,’ i.e., assuming that the average server has a 20% (or whatever your historical metric) utilization, we can virtualize this and put at least 5 of these virtual machines on the same piece of metal that initially held one of these. Instant, very provable ROI.
Intelligent optimization
Does this sound like a recipe for disaster? It isn’t necessarily that as long as you understand the use cases on the individual servers (context variable) and their seasonality (context variable). If you don’t, and in the past, people didn’t, then events such as cyber Monday become an infrastructure blood bath.
Today’s administrative tools are intelligent enough to understand when workload spikes and can move workload around, obfuscating the machines below to us and ensuring that capacity could potentially grow and shrink with need. Assuming there is enough capacity (context variable) sitting around. There are some cool ways to optimize here further that I hope to get into in future writing.
Sidebar: Did you know there are already all kinds of measurements to efficiency formulas to understand power consumption in a datacenter? PUE (Power Usage Effectiveness) is calculated by using a ratio to look at your power consumption from the datacenter + IT infrastructure over the power consumption of the IT Infrastructure, with the ideal number being the impossible 1. Power conversion, power storage in a UPS, etc., all have a power overhead. Minimizing these conversions and storage losses moves you closer and closer to that magical 1.
I’m sure you aren’t shocked that significant time is being spent ‘gaming’ the ratio. Some of which are almost adorable in simplicity and cheekiness.
Goal Setting
Let us look at goal setting and how you prioritize what’s going on in optimizing technology. Are you optimizing to remove the human variables? Do you want an essentially lights-out facility? Well, then you want to standardize as much as you can. Reduce the number of vendors, understand the components’ life cycles, and understand how many of them may fail in a given them. Then put into place a fail-over plan that covers the intervals between planned maintenance. Congratulations, you just built a lights-out facility in the arctic circle, a high-tech facility whose only on-site employees are security.
At this point, you may ask:
What are the lessons from this for the rest of us that don’t have hyperscale data centers?
and
Wait…Why are you even telling me about a hyperscale data center?
The lessons are transferable to any modern system, and many of us already do this.
Optimizing modern technology workflows and systems incurs most of the work at the planning stage. You need to understand the variables that exist, what can be optimized, what cannot be optimized. And maybe even more important the context variables that you can’t influence but that influence your operations.
Are you trying to optimize the power consumption of cooling infrastructure?
Great.
Can you move the location of the facility to a climate that benefits your operations? No? Well, then weather/temperature becomes a context variable in your optimization goals. The secret here is to make the systems optimize as containable as possible, limit variables right. Again, not telling you anything new here, just some common sense. However, we should also look at as ‘are we trying to optimize as far as we can, or is there a sweet spot where diminishing returns may set in?’ I think logistics is an outstanding example of one of these ‘sweet spot’ optimizations.
Let’s look at a real-world example from a different space (but IoT related)
“If you think that 10% of shipments are late, it stands to reason that the majority of the other 90% are actually early, and that’s an entirely distinct problem.”
A shipment arriving early, many incur additional storage costs, there may be no one there to accept it/no available slots. It may incur inventory carry costs that are unanticipated. Hence, it’s crucial to hit that sweet spot exactly. People that know logistics know that it’s still very much an inexact science today. Hitting the sweet spot is a dream because, at least in logistics, we don’t always even have access to all the variables and data required to optimize. Honestly, probably any environment at this time. There is always more to learn.
In the end, the gift of IoT to me comes in space sensing and object state sensing. The richness in variables it unlocks can help with easy what-if analysis, understanding historical data with access to all the variables. See real-time state, and eventually, when you have enough data, achieve predictive analytics and maybe even self-healing in more and more fields. AI is often maligned as the coming great destroyer of jobs, and perhaps it will be. Still, in the short term, AI/ML will be one of the greatest aids to help humans do their jobs better and unlock the incredible insight from volumes of data that couldn’t be collected in the past (or stored) and definitely not accurately evaluated.
No comments:
Post a Comment