With event, incident and problem management, the first thing you have to do is integrate
your cloud environment, alerting flow into your service management toolset, either through
ServiceNow or another platform. The human processes initially stay the same: an event
gets raised and goes into the service desk; if there is an incident, it gets resolved. While the
processes stay the same, how you are going to resolve the issue changes? This will be an
incremental change at first, but the increasing adoption of automation will drive the
breadth of issues getting resolved without manual intervention. There may be whole
classes of incidents/requests, such as the resource scaling removal of temporary resources,
which can be handled through automatic rules addressed in the environment. Historically,
if you had an outage, human intervention would resolve the issue. Now, you can have issues
raised and closed automatically through the adoption of architecture and operational prin-
ciples of autoscaling, self-healing and immutable infrastructure.
While you can reuse a great deal of your existing service desk capabilities, you will need to
plan for the alert integration from your cloud estate and begin to think through the classes
of issues that can be streamlined and addressed through automation.
Logging and Monitoring
While existing logging and monitoring strategies can easily be modified to support data
inflow from the cloud, there are a few key differences to consider. First, while you can often
reuse existing log aggregation or security incident and event monitoring platforms, you
will need to integrate them with cloud provider data flows.
Next, you will need to make sure your team understands the key differences between
on-premises and cloud architectures. Training IT and security ops personnel on cloud
architecture helps ensure they are responding to real signals and not noise based on leg-
acy architectural assumptions.
Finally, you should begin to consider the storage needs for your logging data. Key ques-
tions to consider are where the logging “source of truth” resides (the cloud estate or
on-premises), and how that location may change as your adoption of cloud evolves. You
will have access to near infinite storage but should not store what you do not need: Your
budgets are not infinite! Cloud architectures can allow you to easily create additional
enclaves of logging data for various purposes (troubleshooting, forensics, R&D, archiving,
etc). While this flexibility is valuable, defining your access and usage pattern will help you
manage potential egress charges. Furthermore, developing a data retention strategy
based on your regulatory or business requirements for cloud estate logs is important from
the outset. Keep it simple to begin with, and leverage cloud provider tools.
Conclusion
On one level, governance is governance: It is about keeping track of what you have and the
processes you follow. But governance in the cloud cannot be just a carbon copy of gover-
nance on-premises. It has to be constructed with cloud needs in mind, because it is going
to drive the future of your cloud operations.
WINTER 2019 | THE DOPPLER | 73