- [Instructor] Let's talk about making sense
of all of this and what this means.
So what's important here is that the real trick
is making all of the components you picked work
and play well together.
So keep in mind you may make mistakes.
You may pick the wrong component.
You may pick the wrong storage level,
the database, the wrong kinds of application platforms.
That's okay and the great thing about cloud
is that volatility is placed into a domain
and it's just a matter of configuration
to pick different components that are going
to work and play well together.
So keep in mind this is going
to be a continuous improvement
and you can make adjustments at any time
for any reason to meet the needs of your application,
to meet the needs of the business.
So ultimately, this is about you
making a concerted effort to pick the right components,
but understand that you were able
to reevaluate your decisions
at many times down in the process.
You need to work from the general to the particular,
so we're working from the more generalized understanding
what a cloud computing architecture is,
typically the logical architecture,
to the particular technology.
Never work from the particular technology
that you may be using because it's hiked
or you want to use it, or you know more about it,
or some sort of a bias that's there
and then try to force fit a solution into that technology.
which get into a common logical architecture,
which get into a detailed physical architecture
as to what physical architecture patterns
you need to leverage, different network patterns,
application patterns, database patterns,
things like that and then you pick the technology.
Then you are going to have a much better understanding
what the technology does and how
it's going to meet the needs of your business.
So cloud architecture, we have the levels
application, network, processing, data level, storage level
and we need to turn that into a logical architecture.
In other words, basically an architecture
where the physical attributes are removed.
We're not dealing with a particular physical technology.
Then we do the physical architecture.
We're able to, in essence,
take the logical architecture
and all the patterns we're able to define
and then pick the physical patterns.
In other words, what kind of networking do we need?
Is it a DNS on premise or a DNS off premise?
You know how are we dealing with
intra-cloud networking things like that.
So pick the idea of the solution, ultimately,
and then the technology that's able to solve the issue.
Then you need to test and deploy.
You have to remember that not all technologies
are going to work as defined and so
in many instances the vendors are going
to explain things to you that you assume will
be true and in some instances it may not work
with your particular use case.
And so in other words there maybe some sort
of a conflict that's using a different protocol,
something wasn't thought about,
performance isn't there things like that
and then the only way you and find that out
is by testing before you deploy your solution.
So and when things go wrong don't go with them.
And so I keep in mind that we're going
to have to reinvent this architecture
about once every six months
and that could be a major reinvention
it could be a minor reinvention.
And it's okay to think in those terms
and people have a tendency to think
of architecture as something that's more waterfall
and static when it's iterative
and it allows you the ability to change things as you go.
So don't worry about making mistakes they won't kill you
but what will kill you is your inability
to recognize a mistake and correct it as you go.