>> Good afternoon, everybody and
welcome to the final session --
Cloud Management, Cloud
Evolution and What's Next.
So you've heard the
previous panels take you
through the cloud
journey starting
with the whole cloud strategy
-- what do you need to buy,
how do you procure it, and how
do you migrate your workloads.
And, again, what we are going to
do is focus on what comes next,
what happens when you actually
implement your workloads
in the cloud, how do you
actually operate in the cloud.
So, again, my name
is Moses Merchant.
I'm from Agilious.
And we have a great
panel over here for you
for this event starting with
Vikas Sharma on my left.
Vikas is the chief solutions
architect at Sevatec.
Vikas, 30 seconds, what's
your favorite cloud acronym
or buzzword?
>> My favorite buzzword
is transformational.
And I'll explain it.
>> Okay. Well, okay, cool.
Next up over there,
on the far right
over there, is Adam Clater.
And Adam is the chief architect
at the North America Public
Sector division of Red Hat.
>> Yeah, --
>> All right.
>> Thanks for having me.
>> Your favorite buzzword?
Your favorite cloud story?
>> Yeah, so I think one of
the things that I've heard is
when your cloud bill
gets to around $100,000,
your cloud salesperson
never stops calling you.
But when it gets to
a million dollars,
they never call you back.
Right? And, so, it's
just the idea
of how do we put the control
back in the consumer of cloud,
right, rather than
having folks locked in?
And I hope we're going
talk a lot about that,
and how to make sure our
workloads are portable,
and we're smart consumers of
cloud as we enter into all this.
>> Excellent.
Finally, we have Dan Prieto.
And Dan is the strategic
executive
from a small company
called Google.
They make search engines.
Dan, what is the airspeed
velocity of an unladen swallow?
>> I had to google this.
Eleven --
>> What?
>> Meters per second.
>> What? African swallow.
>> 11.15 meters per second.
>> All right.
[inaudible] --
>> Thank you.
>> Favorite story.
>> I don't know if
it's so much a story.
But I think given the
composition of much
of the audience today,
acquisition professionals,
I think it's important
to realize sort
of the brave new world
that we're entering.
The Federal Acquisition
Register, the FAR,
includes the word "cloud"
exactly zero times.
If you extend that
search to the DFAR,
the word "cloud"
shows up six times.
OMB A-130, governing the
strategic management of IT,
which was just updated
in mid-to-late-2016,
only includes the word
"cloud" three times.
And I was at the White
House at the time,
on the National Security
Council staff.
I was a DOD prior to that and I
helped push that document out.
Times they are a-changing.
And that's really the focus
of the conversation today.
And it's not just about
understanding tech.
It's about understanding
the impact on business
and culture of that tech.
So I think that's
really going to be a lot
of the focus of our talk today.
>> All right.
So, folks, we have some really
smart people on the stage
over here, barring myself.
So then, without
any further ado,
let's jump into the
discussion over here.
Let's start with an
important milestone.
Some of you have
already crossed it.
Some of you are getting
over there very soon,
and making your way towards it.
And that's deploying your
first application in the cloud.
Right? So, Vikas, let
me start with you.
You've successfully deployed
your first application.
No one's complaining.
So in your experience, what
are the important things
that one should be thinking
about at this stage?
What do you need to
do at a strategic
and operational level
at this stage?
>> Right. Thank you.
Thank you, Moses.
So, first, I'll start
with admitting it's bit
of a hypothetical question,
because given the size
and organization structure
of the agencies,
there won't be one.
There will be many.
Two, three.
One per program office or center
or service or business unit.
So they'll all be
going to the cloud.
But this question, when the
panel selected it, was intended
to be a table setter for the
conversation that follows.
And let me try to start
off that conversation.
Folks do a lot of stuff
after they achieve.
So you just got your first
system and ATO, production ATO,
in your enterprise
cloud environments.
So a lot of stuff has already
happened before you did that.
But at this point when
your first ATO is granted,
I would strongly urge people
to use this first experience
as a learning experiment,
and gather
and leverage those
lessons learned
across the entire enterprise.
How do we do that?
We do an enterprise
retrospective.
You can get some agile
coaches, acquire services
or some agile coaches to help
you along with that activity,
but, at a minimum, your group
of people who are engaged
in this retrospective, or your
system developers and owners,
your mission folks, IT
operations and infrastructure,
and, absolutely, acquisitions.
There are some critical
lines of inquiry here, okay,
as to what do we do next.
So how was our experience?
Okay? How long did it take?
How many groups did it involve?
Were there shortcomings in
our system or architecture
and configurations that
we had to overcome?
Did the system meet performance
requirements not only
for itself, but every upstream
and downstream dependency
that the system has?
Was the process of
deployment automated?
If we keep to our current
process, how many updates
and deployments can we do?
Okay? What changes do we need
to make in our operations,
okay, for this system?
If something happened to
that system in production,
what is our contingency plan,
disaster recovery, RTO and RPO,
recovery time objective and
recovery point objective?
How long did the
ATO process take?
Do we expect all
following systems
to follow the same process,
or are we going to
somehow change it?
How do we update, or
do we need to update,
our enterprise threat
model, okay,
because of this new reality
of there being a cloud
in our environment?
What security events do we need
to now monitor and address?
Okay? And are you
seeing the cost savings
that you perhaps
expected to see?
Very important.
And why and why not?
Finally, we're trying to do this
because we want to learn lessons
to how to do this
faster and cheaper.
Okay? So that's a
pretty significant list.
And the question
naturally arises, right,
that why should we do this?
Okay? It seems a long list.
A lot of very complicated
things.
And for that we have to
kind of step back a bit
and tell a little story.
Okay? Well, after all we
have been developing systems
and running infrastructures
for decades now.
Why do we have to, suddenly
everything has to change?
Okay? What's new?
Okay? What happened?
Okay? So to answer that, it's
necessary to take a step back,
and kind of talk about
a particular story.
First of all, everybody knows
cloud's the thing right now.
Okay? Everybody's doing it.
Everybody's going to the cloud.
Cloud adoption, we had
a little discussion
up in the morning
about cloud adoption.
Cloud adoptions rates
are very nice.
Okay? To me, the
question was why.
Why are people going
to the cloud?
Okay? So we started looking.
And, obviously, what happened
was we found out, you know,
sure, capacity and
elasticity on demand
and cost-effectiveness was the
top two reasons why people were
moving to the cloud.
But there were a whole bunch
of other reasons, okay,
in why they were moving.
And then the other thing
that caught my attention was
certain leadership in industry
that understood the cloud
platform to be that innovation,
that transformational
technology that allows them
to change their organizations,
to finally transform
their organizations
into what they always wanted.
What you folks want
is nothing different
from what those guys want.
More organizational
responsiveness to the mission,
more business agility.
Okay? And the stories
are no different
out in industry or
in government.
Everybody is really looking
for that responsiveness
in the organization and
the business agility.
And, so, that was a big reason
for why they finally
recognized cloud
as that enabling technology.
But what is the cloud?
Is it something new, okay, to
really get overwhelmed about it?
For me as a person who's
been dealing with the cloud
for a while, I know most
of the best technologies
within the cloud exist in
your enterprise right now.
Virtualization containers,
all that stuff, discs,
block storage, optic
storage, everything.
Every base technology that
exists in the cloud exists
in your enterprise right now.
So what's new?
Okay? Well, what the
cloud really did was put
that in a really
smart new package.
So if the internet gave us
the global communication
infrastructure, think
of the cloud
as giving you the global
compute infrastructure
to go along with it.
And all of that just you
get to go to a website,
present your credit
card, and use every one
of these great ideas
in computing
that we have put
together in that package.
That's new.
Okay? How we deliver these
compute services back
to the end users.
That's new.
Okay? And what really
this enabled was
almost transformational.
CEOs and leadership
out in industry have completely
revamped their business models.
They have created entirely
new business models.
And they have brought about,
more than anything else,
the kind of transformation
they were looking for.
And, so, that's why you
have to learn the lessons.
Because the package uses
the same base technologies
in a slightly different way
to enable cloud paradigms
like elasticity on demand and
capacity on demand, time sharing
for your cost effectiveness,
and pay-as-you-go.
So it doesn't make much sense
for anybody to go adopt what is,
yes, a new package, awesome
package of old technology,
and then go about doing the
stuff the way we've been doing
all along.
You can't take your
old infrastructures
and the way you develop
systems, and all that stuff at.
So that's why we have
to learn the lessons.
That's why we do
enterprise retrospectives.
We learn how to change all
the processes from development
to deployment to
operations to security.
That's the first step
that I would recommend
the organizations take.
Thank you.
>> Transformation.
That's the key word
over there right?
Because --
[ Inaudible Speaker ]
Very good, very good.
And --
>> That was my buzzword.
Transformation.
>> Transformation.
And when you talk
about transformation,
I'm sure people have heard
about building things
faster, cheaper, better.
There's the old joke about
pick two of the three.
I think with the cloud
you can get all three.
Right? Faster, cheaper, better.
Is there anything that's
different when you move
to the cloud from moving from a
physical infrastructure or from
like on-prem to the cloud?
Again, if you've just
finished your migration,
you come in the next
day, are there things
which are going to
be the same also?
We spoke about some differences.
Are there things that
are going to be the same?
And does anybody else
on the panel have any
opinion about that?
>> Thanks.
So I think we need to take
a little bit of a step back,
and just think about when we
begin to talk about cloud,
what aspect of cloud are
we really talking about.
So there's infrastructure
as a service,
which I think is really
the classic design
of "I have a virtual
machine or a physical machine
within my data center.
I want someone else to take on
the O&M for ping power and pipe.
And I just want to move that out
to someone else's data center."
But there are other models that
I think we're going to talk
about later on like
platform as a service,
function as a service and,
finally, software as a service.
And I think, by and large,
the consumption characteristics
I've seen throughout the federal
government have been focused
on the two extremes
of that spectrum.
Right? How many folks in
the room are using some sort
of software as a
service for their email?
You've got O365 original.
Right. So for a lot
of organizations
that was actually the
first foray into the cloud.
And now we're looking at some
of these lift-and-shift
type of models.
Right? I want to move
out of my data center
into someone else's data
center so I drop that O&M
for ping, power and pipe.
I'm no longer in the
real estate business.
Which these are all really
intelligent sort of decisions
for a CIO to be making.
But many times that's kind
of closely aligned to more
of a managed services contract.
Right? If I haven't refactored
my application to exist
in that cloud, I'm
really just entering
into a managed services
agreement with a cloud provider,
and then obligating myself
to pay by the minute,
by the hour for that
service as I do that.
So I think we need to carefully
examine the cost benefits
of making these decisions.
Oftentimes that movement
and that lift-and-shift
is quite valuable.
And, so, we do that to stem some
of that short-term
hemorrhaging of cash.
Right? But if it is
more valuable, in fact,
for us to enter
into a traditional
managed services agreement,
I wouldn't necessarily
be afraid of doing that.
So I think you have to look at
what level you're really looking
to attack, and what the goal
of the organization actually
is beyond moving to cloud,
which I think has
been a big driver.
>> I want to pick up
on that and also pick
up on the Vikas' comments.
Once you get your toe
in the water on cloud,
I think it's important not to
focus on the technical aspects
of it, but, as some of the other
panels before us, is that focus
on sort of the business
implications of it.
Because, if you ask
that question,
why am I doing this
cloud project
and what benefits is it having,
it will tell you whether you
are taking full advantage
of what the cloud
can offer or not.
Am I doing a cloud project
simply to save costs?
Perfectly valid reason.
There's been a push
for many years to sort
of improve cost management
in government, obviously.
But that is sort of the most
basic proposition of the cloud.
You could go further
and say, "Well,
am I actually getting
significant
performance improvement?"
That is a more mature
and strategic view.
You could go further and say,
"Is it transforming my approach
to security, because I am
now no longer responsible
for what I've moved to the
cloud for the patch management
or the lifecycle management,
and that's now up to the CSP?"
That is another consideration.
And the final most
strategic consideration is,
"Is my cloud project and my view
of how I'm going to use cloud,
does it actually
help me modernize?
Does it actually
help me innovate?"
Right? And those are different
value propositions from cloud.
In my view, the big push
to cloud that we are
in right now actually has a very
specific point in time impetus.
I think the focus on cloud,
in my view from when I was
at the White House,
stems to be frank
from the aftermath
of the OPM breach.
That is the first time that all
of these formerly
separate conversations --
cost reduction, security
and modernization --
those had been long
trends, but they had tended
to be treated separately.
OPM brought all of
those together,
and OPM said, "Well,
wait a minute.
You can kill each of
these birds with a stone,
and that stone is either
shared services or cloud."
So the big push to say it's
okay to outsource key functions
around IT happened
under the tail end
of the Obama administration.
We focused on shared
services and cloud.
This administration has
actually picked up the ball,
and been pretty continuous,
and has shifted more and more
to cloud on balance, even
more so than shared services.
So once you dip your toe in
the water, step back and say,
"How is this project
setting us forth on a journey
to take full advantage of what
cloud can offer over time?"
[ Inaudible Speaker ]
Absolutely.
So I spoke a little bit about
sort of the ongoing O&M costs,
whether that be in your data
center, or whether that be
in a cloud environment.
So the reality is if
as the CIO we decide
to buy some technology,
and it costs us $100,000,
but there's a million dollars
on the back end of man hours
and operational cost in seeing
that technology to fruition,
that's a pretty significant
cost overall.
And, so, we need
to make evaluations
about should we be
buying this as a service,
rather than really trying
to build this technology
on our own, or building this
upon an infrastructure stack,
where we have to be responsible
for all of that management.
And then I think Maria [assumed
spelling] actually did a really
nice job in the last session
of illustrating the value
of monitoring, and having an
understanding of all the things
that you're deploying.
So she said when
she first got there,
they couldn't tell her
what was on the network,
what was the top five
consumers in network traffic.
They couldn't even begin to
put their finger on that.
But now she has capability in
her cloud environment to have
that charge back and show
back of resource utilization,
and say, "Oh, we need
to turn this off.
We need to turn the lights
off when we're done building
or using a particular workload."
Because the potential for run-up
of those costs is
quite dramatic.
And, so, what I would say
is that, yes, management
and management tools
are a critical component
of being successful
in the cloud.
But I think the tenant that we
have to really take with us is
that it's automation
of that management.
If we have human capital
individuals managing resources
directly within our
cloud environment,
it's an incredibly
expensive way to do that.
Right? So if you have a human
deploying a server in a cloud,
and it takes them an hour
to execute on that task,
and that would really
be great, right,
if one individual could do
that in an hour, that's a task
that could be automated
to happen
within seconds or even minutes.
And that's a fully
secured implementation
of that infrastructure.
So I really think that
automation of a lot
of these tasks, the
security evaluations,
the implementations, the
deployment of our technologies
as we look to move into
cloud, that's really the tool
that needs to be, in my opinion,
one of the biggest
parts of that.
I think the good news is
that learning the skills
and the practices of
automation are something
that you can do sort of
within your own data center.
Right? You can begin to automate
within your existing
infrastructure,
and really not make a huge
expenditure in the cloud
in learning how to
automate the cloud.
So what I would say is that kind
of use that as an opportunity
to get your internal
house in order,
and begin to automate
those workloads internally.
And then automate their
deployment to that cloud.
I believe that once we've
executed on that automation
into a cloud, we begin to
figure out how we're going
to automate ourselves
out of that cloud.
And, so, in the next generation
of cloud consumption
the portability
of workloads is going to
become really important.
If, in fact, we're
able to capitalize
on spot market opportunities
within the cloud marketplace,
our ability to move
those workloads
between the clouds is
going to be the only way
that we can realize those
financial opportunities.
[ Inaudible Speaker ]
>> Yeah, so I think the vendor
community has been pretty adept
at cloud enabling.
I think we're getting
much closer
to actually cloud-enabled tools
than maybe we were
a few years ago
when I think the focus was
really on cloud washing.
Right? Which was just, "Hey,
look, we've added cloud
to the name of this, and now
you can use it in the cloud,
and it's going to help."
And, so, yes, I would say that
many of the, there's a lot
of maturity in the
toolsets today.
But there are also going to
be new tools that you're going
to seek out and that
you're going to use.
A lot of those tools are really
going to be cloud-native.
You're not going
to necessarily want
to deploy a complex monitoring
system into your cloud in order
to get a lot of the information.
You're going to use some
sort of subscription software
as a service monitoring tool,
and then consolidate that.
But I think one of the rather
daunting tasks of a CIO is,
certainly, going to be how do
I integrate the things that are
in the cloud that I'm buying
today with the technologies
that are still within
my data center?
There was some discussion
earlier today
on what workloads are or are
not appropriate for a cloud.
And for certain agencies
there are workloads
that may not ever
move to a cloud.
I think those expectations
are constantly evolving.
So the workload we might not
move today, we may be looking
to move a year to five from now.
But, in the meantime,
that integration
of exposing the business value
that is available in the cloud
to whether that be
our internal data,
or even our internal
applications, is certainly one
of the tasks that
our CIOs are going
to be responsible
for moving forward.
>> Excellent.
Thank you.
One other concept
that I keep hearing
about for cloud management
and that's pets versus cattle,
which to me is like
very interesting.
Can you tell us a
little bit about that?
What does that mean
-- pets versus cattle?
>> Yeah. Has anyone
else heard that term?
I apologize.
So the idea is that if we have
a server in our data center,
it's really, really important.
Right? We know exactly what
the workload is that's running
on that server all the time.
And, in fact, we
name these servers.
They may have creative names.
When I started out at the Patent
and Trademark Office nearly
20 years ago, we named all
of our servers after
dead rock stars.
Like that was our
server-naming standard.
And they were really our pets.
And someone would say,
"Hey, Lennon just went down,
and McCartney's not
able to this or that."
And, so, that was a real part
of how we managed
our infrastructure.
And we knew the version
of the operating system
and the patch level.
And we knew all these
things about these servers.
And we really treated
them like pets.
But in the cloud
environment we don't do that.
We don't do that at all.
And the idea is that if
you've got a herd of animals,
and one gets sick, you
don't necessarily take it
to the vet to get it fixed.
Right? You may just cycle it
out of your production system.
And you'll bring in another
cow or mule, or what have you,
to sort of fulfill that spot.
And, so, rather than sort
of making that investment
on an individual basis for
each individual server,
and really taking care of them,
we really just have this idea
that we can build
a brand new server
with this capability
instantaneously in the cloud.
And I think that really
speaks to the automation story
as well is that as
we automate that,
we're able to guarantee
consistency
across all of those servers.
So, hopefully, without too much
of the gore I illustrated a bit.
And I realize Paul
McCartney's not dead.
And there's some debate on that.
There has been, some
of you remember.
But he's not dead.
Just released a new
album actually.
>> Very good.
Well, let's come
back to automation
and more specifically DevOps.
Who on the panel would like
to define DevOps for me?
>> So DevOps, it's not
a complicated definition
in my mind.
It's best defined as a
culture of collaboration
between your developers
and your IT operations
and all operations teams
to deliver effectively
on the mission.
When do we start
thinking about DevOps?
My suggestion is before
you go to the cloud.
Because if you're going to
define DevOps in the name
of collaboration between teams,
I mean, who doesn't want that?
Okay, right?
So start thinking about it
before you go to the cloud.
Also I do not know any way
to do cloud effectively
without Agilent DevOps?
I can do cloud without
those things, yes.
Just not effectively.
And what is automation
and context of DevOps?
So I tend to think of
automation as the implementation
of that before-mentioned
collaboration.
I mean, you can ask
the question, "Okay,
so what form does this
collaboration take?
Do we talk a lot
among each other?"
We already do that.
No. We write automation
software to automate stuff.
We want to do two things in
our DevOps implementations.
We want to automate our software
engineering lifecycle as much
as possible to actually
develop the systems.
And we call those
CI/CD pipelines.
And there was a continuous --
>> And CI/CD stands for?
>> Continuous integration and
continuous delivery pipelines.
Okay? And all the code
that goes and enables
that automation to within it.
The continuous integration
pipeline is an integration
engine that integrates all of
your development processes,
enables automated testing.
And the continuous
delivery pipeline,
which lots of software is
written by the ops folks,
or traditionally
were the ops folks,
is about continuously delivering
software to your environment.
So when we operate in the
cloud, we tend to think
of delivering software not
in three-month increments
on whatever and that big
deployment, and everybody stays
up at night, and all that stuff.
No. We do it every day.
Our code goes from our
development environment,
goes through all the testing,
passes all the security checks,
and it's delivered to the cloud.
We don't want big-bang
organization efforts.
I like to think of it we
are modernizing every day.
Just a small bit, but,
yes, modernizing every day.
So what do we have
to do to enable this?
Okay? So I told you
about the continuous
integration pipelines.
But when we write
automation for deployments,
what we are doing is we have
to, let's look at the steps
in the deployment process we
have to provision compute --
your networks, your storages,
certain security stuff on that,
and enterprise services
like logging and monitoring.
And then, of course,
then comes the part
about updates and
patch management.
Okay? You keep on
putting patches on it.
So we write code for it.
We don't do it manually.
So it's written automation so
that none of these instances
that we are deploying, virtual
machines that we are deploying,
and applications
we are deploying,
we are lovingly handcrafting
them.
No. It's part of an automation
pipeline that gets it done.
That's the automation.
And the goal in my
mind of automation is
to take our work force from
what is considered lower-level
activities to higher-value
activities in your operations.
So I don't have to spend hours
and hours taking a disc with me,
or whatever mechanism we
had of updating my servers.
I'd rather to be doing something
else of a higher value.
And I'd let my automation
engine handle the updates
and the configurations
and the provisioning.
So when we build that
automation, developers,
operations, infrastructure
folks, security folks --
why do we need this
collaboration?
Back in the day somebody
asked me,
"Why do you define
it as collaboration?"
And what I did at that time,
I was stumped, but I went
and asked, "Give me your
top five or seven concerns
that you're managing."
I asked that to the
development team, I asked them
from operations,
infrastructure and security.
The lists I got back from these
diverse groups is completely
orthogonally different.
They are managing
different concerns.
And, of course, that's why
we had different groups.
But now since we have to enable
this fast, continuous delivery
of software, we have to develop
a mechanism to do this better.
And automation is their answer.
Okay? So that's my definition.
>> Oh, I'll piggyback on that
and also introduce the concept
of no ops for a server list.
And this speaks to, again,
what the cloud can enable.
Basically, Google, and the
other cloud providers as well,
are increasingly
offering cloud offerings
where you really don't have to
worry about the infrastructure,
or updating the infrastructure,
or writing code
to automate patch management,
lifecycle management,
all of the above.
That is all handled
in the background
by the cloud service provider.
And that is particularly
valuable for use cases
like application development,
working in databases
and analytics, because
it allows, for example,
an app developer to just code.
And when they need more
capacity, it automatically spins
up and the environment has
the tools to allow them
to just focus on the coding.
Similarly on analytics.
A lot of cases, in
our instances,
a lot of automated machine
learning, for example,
allows automation of labeling of
data so that you can just focus
on what the data is
telling you, for example,
to improve a business process.
The analytics folks,
the application developers
don't have to worry
about all the things
in the background.
And, in that case, neither do
the operations IT people inside
the enterprise.
You have the opportunity to
outsource that provisioning,
that configuration,
that patch management,
that lifecycle management to
the cloud service provider.
And with that, actually,
I want to pivot,
because I know this is
one of our questions.
You okay if I pivot to security?
>> Go ahead, yes.
>> In those instances where you
increasingly rely on the CSP
for more of the functions,
configuration, patch management,
lifecycle management, there
is an increasing opportunity
with cloud providers
to really figure
out what your security model is.
Do you take your
old security model
from your legacy
environment, and replicate
that in the cloud environment?
That is more likely to happen
if you simply replicate
your data center,
you lift-and-shift it.
I have the same number
of servers,
but I'm still responsible for
managing all the security.
There is more value
add, potentially,
in saying, "You know what?
I need to come up
with a strategy
where I rely increasingly
on the CSP for security."
Now this is an interesting
point,
because one of the
largest impediments
to cloud migration
continues to be concepts
about is the cloud
provider secure.
In Google's example I'll
give you the following.
We provide a public cloud.
The cloud that you
will be running
on with Google is exactly the
same global infrastructure
that YouTube runs on, that Gmail
runs on, that search runs on.
And, so, the question is,
actually, the proposition is
that Google's interests are
completely aligned with yours
in terms of the network
and cloud services being
performant and available.
Our ability to deliver a YouTube
video in South America any time
of day, any time of night and
under a tenth of a second.
Our global infrastructure
provides that.
We discovered some of the
biggest recent security flaws
because we have security
researchers
in the last three years
we've put 30 billion dollars
into our own infrastructure.
In 2016 Amazon, Microsoft and us
combined put 30 billion dollars
into our infrastructure.
So we're constantly investing.
So that relieves the burden
of investing from you.
And it relieves a lot
of the sort of blocking
and tackling security functions.
Yes, I know my patches aren't
updated, but I haven't got
around to it, so I'll be okay
with an unpatched system
for about six months.
The benefit of relying
on the CSP is
that they are constantly
upgrading the infrastructure
and the patches, and
updating the environment.
Similarly, OMB A-130
requires strong identity,
multi-factor authentication, at
rest and in transit encryption.
There is a long history
of challenged projects
in government of trying
to implement multi-factor
authentication,
trying to implement
encryption in house.
You're now in an environment
where you don't have
to run those kinds of
projects, because what you move
to the cloud is natively
encrypted, what you move
to the cloud automatically
has patch management.
So, really, I go back again
to the FAR, section seven
of the FAR says that when you
write acquisition proposals,
you have to think about
the benefits to government
of what you are acquiring.
The role of the acquisition
community is as a full
and equal player in an
environment with the CIO,
with the CFO, with
the secretary.
You guys play an equal role
in enterprise risk management.
And if you think about that as
your mission, not as learning
about all the technology
of cloud,
but what role can the
acquisition community play
in enterprise risk
management, what can I do
to inject more innovation,
what can I do to buy down
or obsolete technology
that is expensive
to maintain and hard to secure?
When you think about risk
management, don't just think
about risk management of
the acquisition process.
Think about risk management
to the enterprise, the agency,
the department that you are part
of, and how using acquisition
and procurement to get cloud
services can improve your risk
management posture.
That's the right way to think
about the role of acquisition
in here, because it is a
multi-stakeholder sport.
Everyone has the
same objectives.
You can no longer put IT
and business in silos,
or acquisition and IT in silos.
You're all part of trying to
buy down expensive and hard
to secure legacy environments,
and move it to something
that is more nimble, more agile,
more cost effective,
and more secure.
>> How do I FedRAMP
guidelines play a role?
>> Yeah, so the FedRAMP
guidelines were, obviously,
established with a view to
making the process of thinking
about security around
cloud providers more agile
and more efficient.
The FedRAMP office over time
has made a lot of improvements.
I mean, there's still things
they can do to improve.
But I think the important
thing to do is to look
at the FedRAMP requirements,
on the one hand it's
a compliance regime,
on the other hand it does
provide actual security.
But from the acquisition
community I would say this.
Get familiar with
the FedRAMP controls,
understand what they
are trying to achieve
from a security perspective.
I've seen instances where
acquisition professionals sort
of put on the contract dozens
of scores, hundreds of pages
of additional security
appendices.
That isn't necessary.
I think you have to build up
a level of knowledge and trust
about what FedRAMP brings you
from a security perspective.
Try not to bring a bunch of
additional requirements on top
of it, because that, basically,
defeats the time to market,
time to efficiency
benefits of cloud.
And also think about,
if you are going
to bring anything
agency-specific,
is it really achieving something
from a security perspective.
We've seen this in a number of
cloud RFPs lately, where they're
over and above FedRAMP.
There are additional location
specific requirements.
Think that through.
Just because something
is located
in the United States doesn't
necessarily mean it buys you
more security.
It buys you security in
an old version of sort
of physical space
and physical borders.
But that's an outdated
view of security.
If you have strong
multi-factor authentication,
if you have a zero trust
network, like the network
that Google provides, if
you have strong encryption,
the guidance in many
cases actually,
if your data's encrypted and
somebody didn't steal the keys
and you lose the data, you
didn't actually have a breach.
So in that situation
ask yourself,
"What does location-specific
requirement buy me,
or [inaudible] I really have
an outmoded view of security,
where I can increase and rely
on the CSP for the security,
or rely on encryption, or
rely on strong identity,
and not just rely on traditional
perimeter views of security?"
>> Excellent.
Thanks. I'm going to shift
gears a little bit and talk
about agencies that are further
along in their cloud journey.
And, Adam, question for you.
Should agencies institute a
cloud center of excellence
to focus on things like
governance, standardization,
ongoing training,
education programs?
[ Inaudible Speaker ]
>> It is. This one's on.
>> All right.
Thank you.
So establishing a cloud
center of excellence.
Absolutely.
I mean, I think there's
no reason not to.
I think the guidance
that I would give is
that we should start
small, we should start
with an application that's
far away from our data,
something where we
can iterate quickly
and really learn what
these things really mean,
to consume cloud, to implement
DevOps, what an ATO looks like,
what the security
process really is.
Because I think every
organization, every application,
every cloud implementation
is going
to be incredibly different.
And I think that there's just a
ton that can be learned by going
through the process, whether you
take an UTA type of approach,
or what have you,
there's a variety of ways
that you can execute
on something, observe,
make some decisions, and then
reiterate through your activity.
So, yes. Yes, to
all of those things.
I think the other thing
that I would think about,
especially from an acquisition
perspective, is try to buy
as many large components of this
as are available
in the marketplace.
Right? So if we think
about the postal service,
they have a pretty
unique mission.
Right? They are really
responsible
for that last mile of delivery.
And they have some
pretty unique things
that they do in order
to do that.
There are post offices
in every small town,
and they have these
really funky, but iconic,
right-hand-drive
vehicles that are all
over the place delivering mail.
And those are pretty unique,
at least in the North America
marketplace to the post office.
Not a lot of folks out
there are buying a vehicle
that they can't take through
a drive-thru, for example.
But the post office made
an interesting decision.
They had a unique requirement.
They are a government agency.
They needed something that
really wasn't available
in the marketplace otherwise.
And they did not go into
automotive manufacturing.
And I find that astounding,
because I think a lot
of IT organizations within
the government today are
in a very similar state.
They have some unique
requirements.
They have some security
standards.
They are the government.
And they're, in many ways,
going into the process
of manufacturing technology.
But instead, the
postal service found
that they could buy
this in the marketplace.
They might need some
specialized.
And they are iconic.
We all are aware of these
right-hand-drive vehicles.
They're in our society.
And they're really the only
ones that are using them.
But rather than build a
manufacturing facility for them,
they were able to buy
that from industry.
And, so, I think we need to
be very critical about the way
that we go about
these acquisitions.
That we don't need to build
our own technology over
and over and over again.
Because I think ultimately
what happens is it makes a lot
of sense sometimes for a
single agency to do that.
There are really some very
specific environmental
requirements where you need
to build your own technology.
But what we're seeing is
in the aggregate across all
of government when
this begins to happen,
I think it becomes
a bit of waste.
Not in the capital w, I'm going
to call somebody an alert,
an IG, but in the, "Hey, is
that a really good effort?
Are we wasting effort?"
And as we talk about DevOps,
DevOps is about delivering
frequently and the elimination
of waste, that's really where
the kaizen part of DevOps comes
in to this lean capability.
So I would just say think
critically about that.
Should we be building
technology,
or should we be buying
technology?
A-130 would also argue
that you should buy.
>> On that last point,
the OMB A-130,
revision 2016 is very
clear on that front.
When you are making
IT investments
or doing new IT projects,
you need to thoroughly determine
whether the same capability is
out there commercially.
And, if it is, exactly to your
point [inaudible] the post,
you should not be out
there trying to build,
own and operate it yourself.
And cloud, even though OMB
A-130 only has the word
"cloud" three times, cloud
is constantly evolving.
Really dramatically the
capabilities have increased just
over the last couple years.
And, so, that clause inside
A-130 is really at the forefront
when you think about cloud
services versus trying
to continue to sort
of roll your own IT.
>> So on that topic,
what are your thoughts
about [inaudible] sharing best
practices and lessons learned?
>> Well, first of all,
what we are seeing
across the engagements that
we learn lessons from is
that the agencies that are
ahead are actually ahead
in about four axes.
Okay? There are agile
practices, there are DevOps
and automation practices,
cloud management and delivery,
and cloud governance
and security.
That these four axes,
where they have gone,
or they have taken
significant steps
to increase their capabilities.
So that's where the
axes of maturity is
for the various agencies
who are slightly ahead.
Should they share?
Yes. But I am a little
hesitant to say that.
I say that because
that is a good goal.
And you can definitely
leverage lessons learned
at other agencies.
However, agency missions
are very typical,
their organization
is very typical,
the way they deliver
IT is very typical.
Lots of things are
very different.
Point solutions don't
really carry over.
Good ideas will always
carry over.
But not point solutions.
Okay? So it has to be thought
through, if there's going
to be a formal exchange
mechanism to be set up,
how does it operate, what is
the level at which it operates,
and what is the kind of
stuff that we do share.
So I think there will
be some need for that.
Agencies that are ahead are also
ahead in acquisition practices.
They have learned their lessons
of what are the intricacies
of operating in the cloud
that has bearing on cost,
and how they acquire resources.
It is not just about
acquiring resources also.
It is also they are ahead
in terms of how they deliver
to the end users
to your mission.
So we've got this great
package now, great new package.
We acquired it.
And then how do we deliver it
to our end users and mission?
So looking at that,
those mechanisms also,
certain organizations
have made progress.
I have in my mind a sort
of an evolutionary path
that I personally have seen
agencies go through in terms
of delivering to the user.
Because if we don't
make it easy for mission
to consume these resources
that we are acquiring,
your adoption rates
are going to suffer.
People will do their own thing.
They have to deliver
on the mission.
They will do their own thing.
One offs will start coming
up, whatever we have to do
to deliver on the
mission will happen.
Credit card purchases get done,
lots of other things happen.
But as we make it easier
and we impose the governance
and the security policies that
the enterprise would require,
and how we deliver that without
being a barrier to agility
that system owners
would like to see
in their teams, that
is the maturity.
And good ideas will
always transfer.
I have witnessed and listen
to some ex-public servants
who are doing exactly that.
That exchange happens
at the highest levels,
as well as to the
operational levels.
So it is happening.
I am not quite sure if
the question was to set
up a formal mechanism to do it.
I haven't thought about that,
whether there's a
formal mechanism.
But informally it is happening.
>> All right.
I'm just going to pause
over here real quick,
and see if anyone
in the audience has
questions at this stage.
>> Yeah, this is a
question for the panel.
Security is a shared
responsibility.
More so with the evolution of
the cloud, or the qualification
of cloud within the
federal government.
Now, one of the challenges
that we have is,
as we try to bring the solutions
quicker to the user communities,
we are faced with a
shared responsibility
of securing information assets.
In a cloud platform, where you
have different service providers
providing different
capabilities, for example,
infrastructure in service,
or platform in service,
or software in service, and
then then you have the user
communities, do you
have any suggestions
that can be leveraged to
help the system owners
and the administrators
move faster
to get an authorization
to operate?
>> So there were two
questions rolled up in there.
I think one is security
strategy,
which we've addressed
a little bit.
I think it would be a mistake
if you moved to the cloud
to just say, "Look, I'm going to
keep all my old security stuff,
and just try to lift-and-shift
my security over to the cloud."
You are not gaining in
scale, in the efficiencies,
in the effectiveness of
sort of capital expenditures
and technical capabilities
of the cloud providers.
In terms of ATOs, it's
a separate question.
Again, FedRAMP and the
provisional ATOs were meant
to speed the issuance
of ATOs by the agencies
and departments themselves.
And the overall push has
been an attempt to sort
of increase ATO reciprocity.
Oh, they have an ATO.
I'll just sort of borrow theirs,
because they're using
the same cloud provider,
the same service,
and I'll accelerate.
When I was still in government,
and I left in January 2017,
we still hadn't reached
that ideal state.
You still had a lot
of CIOs saying, "Yeah,
I know what's going on
with FedRAMP, but I'm going
to redo some of the evaluations
on my own just so I can sort
of convince myself
and trust it."
Similarly, we've had meetings
with some component CIOs
at certain departments,
where there is a tension
between the CIO and
some of their IT staff,
which is at some point
you just have to trust
that they're FedRAMP, and
not try to ladle on top
of it a bunch of additional
security requirements,
because that's the way
you're used to doing it,
or because that makes
you comfortable,
or because that gives
you a level of visibility
that you think you need.
So this, more than
anything, is a culture change
than a security issue.
I do think, though, it
is important for anyone
in the audience here
to increasingly understand
the capabilities
that the CSPs provide, and to
build that into your strategies.
Google, for example, on both its
productivity suite and its sort
of infrastructure
platform as a service, GCP,
Google Cloud Platform, there
are really robust dashboards
and visualizations that show
you who accessed your data when,
that give you rheostatic control
over who can access
data and when.
Again, there are security
capabilities built
into our cloud fabric
from end to end.
Hardware root of trust,
zero trust network,
not a perimeter model.
Basically, I authenticate
the user,
I authenticate the machine,
and I authenticate their purpose
every time they're accessing a
piece of data.
End-to-end native encryption.
Options on key management.
Do we manage the keys or do you?
And, again, these visualization
dashboards can give you status
at any moment, who's pinging my
data, where is the inbound IP,
what's the outbound IP.
And then encryption.
Again, in many of these cases,
and even according to a lot
of state laws and
NIST standards,
if your stuff is fully
encrypted, when you lose it,
you do not have a breach.
So, really, if you
can focus on that,
and not spend all your time
on what people call hygiene,
I have to do the patch
management myself,
it really dramatically
and strategically changes
your security posture.
>> Any other questions?
Okay. I have a couple of
interesting questions over here.
So I'd like to hear from all
of you on the panel, okay,
really quickly, what are some
of the real-life challenges
of working in the cloud?
Right? Are there any brick walls
that you expect agencies to bump
into at a certain
point in their journey?
And how can they
prepare for that?
>> Yeah, I think the two
that I see most frequently are
certainly culture and cost.
There's, Maria mentioned, the
need to turn the lights off
when you're done, or
to shut down workloads.
And, so, the traditional
workloads that we have
in our data center today are
not really optimized for working
in a cloud environment,
by and large.
Right? Just generally
they're not well suited.
So I think you have to be
intentional about how you,
whether it's a refactor or
adapting that application
to work in a cloud
environment, where you do have
that horizontal scalability.
Because sort of the
standard implementation
in a data center has
always been in plus one.
How much do I need?
Add one more.
If one fails then I'm good
to continue operating.
Forklifting that model
into a cloud provider
is incredibly expensive,
and is really not the way
that that's designed to work.
So I think that's
really the intersection
of cost and culture.
We have this idea that we need
more than we're going to use.
And then, by virtue, we
use more than we need.
And, so, it's really focusing on
that application and determining
that horizontal scalability.
And then I think long
term, as I mentioned,
once you have a workload
that you're able
to scale horizontally
and decouple
from a very specific
cloud implementation,
you as the consumer get to have
a lot of choice about where
that workload lives,
who is going
to be your cloud provider today.
If it's a nickel a CPU
minute, then go over there.
But if you get it for four
cents, let's have the ability
to move our workloads.
And, so, today, one last
thing that I'll say,
and I know we're running short
on time, is that when you flip
on a light switch, you
don't think about where
that power is coming from,
whether it's hydro or solar
or even coal or nuclear.
And when you go and buy a
television, you don't think
about where that's coming from.
But today as an IT organization
when you go to build a piece
of functionality, you're doing
a lot of thinking about where
that compute and how
that compute is going
to be surfaced to you.
And, so, ideally,
we get to a point
where that's no longer
a stumbling block.
>> Vikas, do you have
anything to add over there?
I do want to get to one
final question over here.
>> Just, again, cost and the
huge culture change from one
of CapEx in a long
tail of O&M that eats
up 75% of your IT budget.
Cloud is a completely
different cost model.
And, so, to have it work inside
the business it requires close
collaboration between IT
professionals, CFO's office,
acquisition professionals.
I mean, this is a huge change in
how you think about budgeting,
how you think about dollars, how
you think about cost controls.
And, so, it's important for
acquisition officials to move
to a period again where
they're looking at risk
to the enterprise, not so
much risk of the IT project.
I think some of the
other barriers, you know,
you look at the commercials.
Everything is like
everything goes to cloud.
The reality is for a
long time you will end
up being a hybrid
multi-cloud enterprise.
Not everything is going
to shift to cloud.
You will have stuff
some on-prem.
You'll have some
stuff in the cloud.
And, to be honest,
for resilience
and performance issues, you will
want multiple cloud vendors.
There is a maturity level,
an awareness level that comes
from managing a hybrid
environment.
Right? So, yes, that is a new
kind of expertise that needs
to be developed to manage a
hybrid multi-cloud environment
in a way that is
optimal for you.
I do think, however, net-net,
it dramatically increases
costs certainly on the CapEx
and O&M side,
and it dramatically reduces
risk to the enterprise.
But that is a place
where you need to invest.
The other thing is that
to take full advantage
of the cloud environment
you often have to refactor
that data and application.
Sometimes, again, you need to
spend a penny to save a nickel.
So that also raises questions.
And things like the new IT
modernization fund are out there
to try to help transition
people across that transom.
But those are some of the things
I think that are important.
>> Continue on.
Final thoughts.
We are out of time.
So just what is next in
the cloud evolution cycle,
what are some new technologies
that we should be
getting excited about,
what does the future hold?
>> Right. So it's a truism that
by the time you are done setting
up your enterprise
cloud environments,
the state of the art, as far
as the vendors are concerned,
has already gone ahead.
But what's next for cloud?
What is Cloud 2.0 in government?
Generally, we see
a certain state
of the art across agencies.
And, obviously, the
question, "What next," is,
"What next for you folks?"
Okay? In my mind,
operationally speaking,
Cloud 2.0 in government
is simply a self-aware,
self-healing autonomous
environment
with an eye towards
manageability, security
and cost transparency.
You have certain features.
Self-service.
We would like our end users
to just go up to a portal,
and acquire the services
they need.
Automated deployments, automated
onboarding, ITSM integration.
We want our IT service
manage to integrate it
into our cloud platforms.
Serverless micro
services, no-ops,
cloud-native mission
critical systems.
Okay? Serverless
management services,
the cloud management services.
Security is as serious
as active defense.
We want to be proactive with
our defense, not react to events
that happen, security
events that happen.
Okay? Automated governance
and policy enforcement.
We would like that
to be automated.
Okay? And we want a full
environment monitoring
with a machine learning
and AI-based response
to those events that happen
in the other environment.
So this is where you start
putting in more intelligence
into your environment itself,
your operating environment
itself.
So these are some of the
features that I see coming.
These are some of
the technology.
When we were dreaming about
this a few years back,
the base technologies,
it was a long shot,
because the base
technologies did not exist.
But every one of these things
is, in one form or the other,
is available in the market.
And it's a matter of
crafting a solution
to bring it to government.
>> All right.
Thirty seconds, Dan.
Thirty seconds to Adam.
>> All right.
So I think Vikas made
a really good point.
And that is that there really
is no end state in technology.
Right? And, so, I
think that as we enter
into these acquisitions,
we have to be very aware
that change is on the horizon.
Change is coming
very, very quickly.
We need to think
very differently
about how the timeframes
and the methods
in which we're making
these acquisitions.
And the reality is that
success will not be defined
by the technology
acquisition that we make.
It'll be defined by how
well we prepare ourselves
for that change that
is imminent.
>> Last comment.
I think we have to
move from the idea
that the cloud is simply
move my data center
to somebody else owning it.
That is not the promise
of cloud.
The promise of cloud,
in my view,
is further up the value
chain as Vikas said.
For example, analytics.
It is true that inside
government enterprises there is
an enormous amount of
trapped data about programs,
about customers, about
enterprise performance that all,
in my view, if unlocked
properly,
using really inexpensive
compute power,
analytics machine learning and
AI, has the ability, really,
back to the transformation
beginning,
transform how government
does its business.
But you will not get there
if you put a glass ceiling
on yourself, and say, "Well,
all I'm doing is lifting
and shifting my data center."
No, the reality is to use
these continually evolving
capabilities to get much
better insight into how
to run your enterprise, run your
department, run your agency,
and better serve citizens.
That to me is the
promise of cloud.
Doing that inexpensively without
having to buy your own servers,
buy your own licenses,
manage your own environment.
Let somebody else do all
the blocking and tackling.
You focus on your
mission, and you focus
on doing your mission better.
>> Excellent.
Well, that concludes
our session.
I would like to thank
our esteemed panel.
Thank you all for coming.
And have a wonderful
rest of the afternoon.
