- [Presenter] At the intersection of DevOps values,
and legacy, regulated, and nonautomated environments,
focus on the A and the S in CAMS.
Automation and sharing.
Automation will be constrained by legacy environments that
don't lend themselves to automation,
or don't make business sense to automate,
because release cycles, for example, are infrequent.
The obviously thing to do here is to move off
legacy environments to the cloud to enable automation
where it makes sense to do so.
But if that's not possible or business-justified,
you can still apply the DevOps value of sharing for tools.
Often, tools such as monitoring tools, are not shared
across DevonOps and legacy environments for no good reason.
This creates an unnecessary divide between DevonOps,
especially around nonfunctional requirements,
which ITIL calls the warranty aspects of a service.
So give some thought to sharing tools
to break down that barrier.
At the intersection of DevOps principles, the three ways,
and legacy, regulated, and nonautomated environments,
consider applying the first principle, systems thinking.
Often in enterprise environments, we have islands of systems
that are optimized locally, but when you move up a zoom
level and look at the whole systems,
what you see is dysfunction.
One way to attack this problem is to create consistent
standard processes common across all platforms.
The key is consistency.
Change is change is change, for example.
Have the same standards across all types of systems,
allowing people and automation to meet these standards
in different ways, for different systems,
based on their capacity to do so.
Set a roadmap to retirement for legacy systems,
except where they're still best in breed.
And as some legacy systems with slow chain cycles
are not worth automating,
instead, focus on high-velocity change environments
that lend themselves to DevOps.
For these systems, for regulatory compliance,
set standards in the processes that own change and release,
and automate compliance.
When DevOps meets legacy, regulated,
and nonautomated environments, the two DevOps methods that
stand out are continuous delivery
and infrastructure automation.
Unfortunately, these methods may be out of reach,
either technically or for business reasons.
The view may not be worth the climb for legacy environments.
Having said this, the idea is to move to the cloud where
you can, and to plan the retirement of legacy systems.
In the meantime, some aspects of continuous delivery
and infrastructure automation may be applicable
for some legacy environments.
The thing to do here is to make a business assessment
as to where the view is worth the climb,
and to make improvements there.
Do what you can.
The DevOps practice most relevant to legacy, regulated,
and nonautomated environments is
of course the use of the cloud.
One thing you should know is that cloud providers pursue
regulatory compliance for their platforms.
Freeing you to focus on compliance
for you applications and services.
So, cut over to the cloud where it makes sense to enable
DevOps, and to reduce regulatory overhead that must
be handled in-house.
What should, and can you do, that's DevOps see
and makes sense with your traditional infrastructure
while you continue the march to the cloud?
First, put plans in place to retire legacy environments.
Then, prioritize what to move to the cloud.
Slow-moving platforms that will eventually be retired
and don't lend themselves to automation
should come after others.
And where it doesn't make sense to cut over the cloud,
it may make sense to apply extreme standardization
to legacy IT in the interim, to ease the overhead
of managing these platforms.
At the intersection of DevOps tools and legacy,
regulated, and non automated environments,
you should know that the DevOps tool chain criteria
is that each tool should have not just a UI,
but also an API and command line interface.
While you may not be in a position yet to retire legacy,
what you can do is change how you manage it.
There's no reason why you can't apply at least some
modern management practices to legacy targets.
So one thing you can do here is to review your tool set
against the DevOps tool chain criteria,
and adjust what tools you used based on your analysis.
You want to connect these tools in the chain with chat ops,
which can be pointed at legacy environments
just as well as cloud environments.
The benefit here is that the conversations and
automated remediations are captured and timestamped.
And that enables blameless postmortems.