(upbeat music)
- [David] Let's talk about the concept
of distributed architectures.
First and foremost, distributed architectures
are nothing new, they've been around for a long time.
We've been dealing with distributed systems
for about 30, 40 years.
As soon as the network showed up,
we learned how to push different parts of the application,
different parts of the data retention systems off
to different systems.
And really, if you look at what cloud computing is,
it's kind of the mother of all distributed computing systems
at the end of the day.
So what's important here is that most of the cloud solutions
you're going to design are going to be very distributed.
That's just the nature of the beast.
And we're going to distribute them typically
over very high latency networks, such as the open internet.
And we're going to be dealing with a number
of different issues that come from the distribution
of these applications.
And so where there's a benefit for distributing the load
and distributing the data across many entities
that are network connected,
there's going to be some downsides there as well.
So in many instances, you're going to be leveraging
multiple clouds, they're called multi-cloud,
the ability to leverage Amazon and Microsoft
and Google at the same time.
And you're typically going to be dealing
with advanced architectures that are going to be multi-cloud.
They're going to be dealing with more than one public cloud.
They're going to be dealing with a private cloud
in some instances.
But typically, it's going to be a hodgepodge
of traditional systems, traditional databases,
as well as net new databases, purpose-built databases,
such as in-memory databases, time series databases,
that's mixed and matched
with different public cloud providers, such as AWS,
Microsoft, Google, perhaps Alibaba.
So we have cloud governance,
which really is the center of the universe
for distributed systems.
You got to remember, part of being an architect
is coming up with advanced solutions
that are going to remove the human beings
from having to deal with the minutia of the architecture.
And we're going to find that the more details
that we have to deal with,
the more we're going to need governance
or abstraction services,
which is going to sit between us
and the complexity of the systems.
So we have methodologies,
we have key performance indicators, KPIs, and monitoring,
we have lifecycle, we have processes,
we have certifications that are going to be part of it.
Technology, such as quality of service, standards, tools,
portfolios, things like that, that we're dealing with.
And then people, organization, competency, incentives,
rules, responsibilities, all these things
we have to keep in mind.
So going forward, this is really about keeping
a lot of this stuff at bay
by leveraging advanced cloud governance systems
that's able to communicate with technology processes
and people, which are in turn able to communicate
with organizations, competencies,
roles and responsibilities, those sorts of things.
Core to being an architect
is dealing with technology and processes.
People are going to be an aspect of it,
but at the end of the day, we're trying to remove ourselves
from dealing with the underlying complexity
of what these processes are and these technologies are.
You need to set this up so that the cloud governance
is going to be keeping a volatility into a domain.
And so do very simple configuration changes,
in this case with cloud governance
and changing the policies,
we're able to redo how we're dealing with processes
and technologies and how we're dealing with tools
and portfolios and all these things
that are basically in the past have driven us
to rewrite or redo the existing architectures
to accommodate the changes, and we can no longer do that.
And you can't do that at the speed of need,
you can't do that as quickly as we need to move.
Today, you have to be able to place that volatility
into a single domain.
That's typically going to be some cloud governance system,
either resource governance or service governance,
API-based governance, things like that,
where configurations can be changed
to accommodate any changes to the architecture.
So the rise of distribution and complexity
are really kind of depicted in this particular diagram.
We have service-oriented architecture, security, data,
provisioning, tenancy, all these things
that are very important to hybrid
and multi-cloud environments that could be private,
public, or community cloud.
So we're dealing with shared services.
We're dealing with private trust, centralized trust
and tiered trust in terms of security.
We're dealing with data at a central level,
at a distributed level and a tiered level.
We're provisioning either self,
within a particular private cloud provider
where you're using it via auto-provisioning mechanisms
that's combined with self and managed provisioning
that occurs within an automation system
that exists on a public cloud.
For example, I can self-provision resources I need,
I can self-provision as well as automate the provisioning
of the resources that I need.
And I can certainly manage those resources
that are provisioned.
So tenancy, we have multi-distributed.
the ability to deal with multi-tenancy
and also distribute tenancies.
In public cloud, we have multi-tendencies
'cause we're dealing with an environment that could host
as many as 1,000 different companies
on a particular cloud instance.
And then community cloud,
we're dealing with managed instances.
(upbeat music)