.svg)
As your device fleets grow from a few to a few dozen to a few thousand, how do you ensure that all your devices are in compliance with your desired state? Especially with complexities where each device (or sets of devices) has its own desired state, and each has different settings, apps, and content to manage? What if one device was compromised and an app that should not be on the device was installed? Do you look at a report of all your devices every day and determine which needs attention? In the meantime, a whole day has gone by without addressing that issue! And, as your fleet continues to grow, the complexities only exponentially multiply!
This is where managing by exception comes into play. It’s a means of managing devices based on the ones that are not in their desired state rather than each one individually or the entire fleet as a whole. Executing this concept may sound tough (infeasible, even), but that’s where Esper Blueprints comes in!
What Is This Blueprints Thing Again?
As you bring new devices online into your fleet, you want to onboard the device to Esper and then immediately provision the device to its desired state. Blueprints is what accomplishes that for you. You define the desired state, tell the device that this is its desired state, and then see the magic happen! With granular control over every single aspect of your device, Blueprints captures — and enforces — that the desired state is where your device ends up after provisioning. It’s all about keeping your devices in that desired state.
Did I pique your interest? Good. Here’s some additional reading around Blueprints and other concepts mentioned earlier:
Now, Let’s Talk About Managing by Exception
Once your device is initially in its desired state, you want to rest assured that the device will stay in that state. And, if you define a new desired state for that device (if you want a new version of your app on the device, for example), then it's updated to that state and stays there.
As great as that sounds, you haven’t even seen the magic yet! Imagine if your device management platform monitored these devices for drift (meaning they are no longer in that desired state you set up earlier) and then notified you via Slack, email, or a ticket in your ticketing system. You could immediately remediate this specific device and bring it back to its desired state.
That is exactly what “managing by exception” is! And that is what Blueprints enables for you (along with the concept of drift management, which we’ll talk about in detail in a future post). Simple. Done. Now go enjoy that coffee break!
I internally refer to the capability of Blueprints and drift as “set it and forget it.” And yes, I do enjoy rotisserie chicken, for those of you who know the reference. 🙂
Think of the alternative — every few hours or every day, you’d troll through a long report, or worse, log in and check each device if it's still in the state you told it to be in. And, of course, you’d miss something — disaster! Painful! Yuck!
You Can Go Way Further With the Power of Blueprints
The thing with Blueprints is that this is just the beginning. This is going to be the foundation of DevOps for Devices. While it's fully functional for desired state management now, it’s early days for this tool (or, dare I say, toy?), and we have plans for some amazing new capabilities to do much more. I don't want to give up too much information right now, but know that I’m not being dramatic when I say that this journey has just begun! I am eager and excited to offer these to you soon!
The future we see will enable organizations to move and scale their device fleets like never before. We’d love to have you along for the ride!
Stay tuned for the other blog posts in this series: drift management and remediation, continuous delivery and automated fleet updates, and device compliance. (And how we'll help you tackle them all!)
FAQ
Keep Exploring
.svg){kind=small}
