Let's talk architecture. Architecture,
at least in information technology terms,
is about the decisions that we make when we're building IT systems or
applications.
Cloud architecture refers to the decisions we make when we're building things
in, well, the cloud, and believe me,
the decisions available to us are aplenty.
Now it takes years of practice and experience to become a good cloud
architect, so we're certainly not going to do it justice here,
but as you've started your cloud journey,
there are a few concepts that might be useful as you build out that business
case. In this module,
we're going to talk about some of the reasons why companies move to the cloud.
We're also going to cover some common cloud migration approaches
and talk about why virtualization and containerization are often
part of cloud adoptions.
There are several reasons why companies may move to the cloud. Now,
of course we could accomplish these things without the cloud,
like we've been doing for years,
but the cloud does introduce some new business capabilities through
cost-effectiveness or accessibility.
A very common reason companies first get interested into the cloud is fault
tolerance. Now, if you're a company that values your existence,
you'll have some sort of disaster recovery plan.
These plans usually involve some alternate place where you can store data,
or you're able to recreate key business systems in the event that your
primary data center has some sort of problem. Now, traditionally,
this was done by contracting with some provider to keep a physical
second copy of your hardware, ready to go at a moment's notice.
Only problem is that when everything's up and running fine,
that backup physical hardware is just sitting around collecting dust and
becoming obsolete, but you're still paying for it. Now, sure,
it's an insurance policy,
but what if there was a better way rather than buying all your backup
equipment? Why not just rent it only when you need it?
Cloud providers have massive amounts of system capacity available to you
in seconds, and you only have to pay for what you use,
which is almost always a huge cost saving.
Then when the crisis is over,
you can just shut those things down and stop paying.
It's the same concept as me taking an Uber or a taxi to get somewhere versus
buying a car. Now, if I need that car all the time,
then it would probably make more sense over time just to buy the car.
But if you're constantly needing your backup site,
then I'm afraid you've got some big problems.
Another reason companies adopt the cloud is scaleability.
Scale is how much or how little capacity we need to meet
business needs. Now,
obviously our goal is to have our capacity as close to our need as
possible, but that's a pretty tricky thing to forecast.
The pay-as-you-go model of cloud providers enables us flexibility and the
ability to scale up or scale down depending on our needs.
Globalization is another common reason for cloud adoption.
As a company grows and expands beyond their home borders it makes sense to have
resources and services close to those new markets,
maybe for regulatory reasons or maybe performance reasons.
Cloud providers already have data centers and resources in various geographies
available, and you can use those with little more than a click of a button.
Perhaps the most valuable business reason for cloud adoption is
agility.
Agility is the ability to respond to changing needs.
In many companies, if I wanted to run an experiment that required IT equipment,
I would likely have to endure a requisition and procurement process and
secure resources from the IT group to set up and maintain that equipment.
And that could take weeks or months. In the cloud,
I could get access to that equipment in a matter of minutes and I could try my
experiment and then shut down the equipment.
I could get my results maybe in a day versus a month.
And it might only cost me a few cents.
Now there are many other ways that the cloud enables agility that we won't go
into here, but know that as abstract as it may seem,
studies have correlated cloud adoption to organizational benefit
through that agility. And then there's cost.
Cost is a funny thing.
While we would like to think it's a very straightforward thing,
the reality is that most companies are not very good at tracking true costs.
With cloud providers, costs are very literal. They show up on a bill.
Some companies are surprised to learn that their costs might be more than what
they believe their onsite data center costs to be.
But pulling together the total cost of ownership or TCO is pretty
difficult.
Are you including power and heating and cooling and fire suppression in your
calculation?
How about any security measures like card readers or security cameras?
Sometimes it's just in how your company chooses to account for your IT
assets that can significantly change the cost landscape.
These hidden costs add up. Now at the opposite end of the spectrum,
if you misuse your cloud resources,
they can easily cost dramatically more than any sort of onsite data center.
And this is why it's so important to train your staff and involve
experienced cloud architects.
A thorough cloud adoption strategy will have specific governance as in-cost
management components. And we're going to cover those in another module.
So cost savings can be realized,
but be careful about the expectations you set,
especially in the early days.
Let's talk about some cloud strategies.
When people say moving to the cloud,
they're usually referring to the public cloud.
These are the big providers like AWS, GCP and Alibaba,
for example.
Some large traditional IT companies like SAP,
IBM and Oracle have created public cloud businesses as a way to
compliment their traditional business.
Microsoft Azure is a good example of this.
We call these public clouds because they're indeed open to the public.
Anybody with an internet connection and a credit card can use their services.
Then we have private clouds.
Private clouds are intended to be used solely by a single organization or a
company.
Companies can set up private clouds in their own data centers or in some other
hosting provider. When companies make use of multiple clouds,
be it public or private, we call this multicloud.
Most established companies will use a multicloud approach,
referred to as hybrid cloud.
Hybrid cloud means that you use both private and public cloud
resources, and maybe you shuffle workloads between them.
It's quite common for companies to use as much of their own computing resources
as possible,
and then use public cloud resources to handle temporary exceptions.
In fact, most companies offer a hybrid cloud approach nowadays. Anyway,
some companies also adopt a multicloud approach that involves
multiple public clouds.
Vendor lock-in is when you become so entrenched with a single vendor that you
may lose flexibility or negotiating position.
Some companies seek to minimize vendor lock-in by using multiple public
clouds. Personally,
I don't get too concerned about vendor lock-in with our current crop of public
cloud providers. As we'll see later in this module,
there are some ways to mitigate that risk. Plus from a skillset standpoint,
having to constantly pivot among multiple public clouds tends to create more
challenges than it really helps.
When contemplating a move to the cloud, there are several common methods.
The first is just simply picking up our existing systems and dropping them on a
cloud provider, same software, same operating system. We call this rehosting,
or it's sometimes called lift and shift as we're just moving things from point a
to point b. Now,
while this is usually the least risky way to migrate to the cloud,
it does not typically offer very much benefit in the long run.
However, it's a very common first step for many companies.
Next we can replatform. Instead of just forklifting our systems over,
we might be able to take advantage of some of the services provided by our cloud
vendor. For example,
instead of recreating our database on its own cloud hosted server,
maybe our cloud provider offers a fully managed version of that same database.
And by using that fully managed version,
we can potentially save on maintenance and fault tolerant costs.
Now we can decide that rather than moving our applications to the cloud,
we might just purchase something that's already in the cloud. For example,
we might decide to license some user accounts or a new HR system or a customer
relationship management system. And that may be already in the cloud.
Workday and Salesforce are examples of these types of systems.
Now, if we wanted to get really ambitious,
we can totally rearchitect our application systems.
We can use all of the various services that our cloud provider has to create
what some people call a cloud native version.
This just means that we're using methods that best take advantage of what our
cloud provider has to offer.
This method tends to yield the best return in the long run,
but it's also the most complex and risky.
Now maybe through the evaluation of our systems and applications,
we figure out that one of our systems isn't being used at all.
And if this is the case, since there's a cost to keeping that system running,
we can retire that system.
Sometimes this is called sunsetting a system or an application.
And of course we can just choose to do nothing.
Maybe through our business case process,
we find that there's no good reason to mess with an existing system.
So we'll just leave it alone. And that's a perfectly valid outcome.
Two concepts that we hear frequently around cloud computing are virtualization
and containerization. Now, if you remember earlier in this module,
I said that cloud providers have massive amounts of computing power available
for you to use in seconds. Well,
they don't have lots of people running around plugging and unplugging cables.
Whenever you request a new system cloud providers make use of virtual systems
or virtualization.
This just means that they can create complete software based computer systems on
top of physical computer hardware. When you request the system,
it can be set up or provisioned, as some people call it, in a matter of seconds.
And when you're done, it just disappears.
And the physical system resources can be reallocated to other
customers.
So what does a cloud provider data center look like from the outside?
They look like a big warehouse. And unless you look really closely,
you probably couldn't tell a data center from any other logistics warehouse.
They're usually heavily secured and have lots of extra power and cooling
equipment around them. Inside, there's going to be rows and rows of racks,
holding physical computers. Of course,
those physical computers will host several virtual systems,
which get rented out to customers like us as we need them.
You might be surprised that these data centers usually only have a very small
handful of people working there.
Most of the maintenance is automated and people are only needed when something
needs a set of physical hands. And data centers are really,
really loud. They have lots of cooling equipment running a full blast,
trying to keep everything from overheating. Now,
an evolution of virtualization is containerization. First,
let me explain the problem that containers are trying to solve.
Let's say that we have a brand new computer system.
Then we start loading software on it. Now,
sometimes one software package might create some conflict with another
software package, and that results in errors or problems.
Now let's say that we get a new computer system and we need to move over some of
that software from the old system to the new system.
And we accidentally leave out part of that software. Well,
that could result in problems too. And in fact,
you might have experienced some of these same problems on your own home
computers, as you try to upgrade them.
Just imagine that problem across hundreds or thousands of systems,
and you can just see what sort of headache that would cause.
Enter containers. Containers are like virtualized systems,
but more lightweight. Think of it as a nice,
neat little box that's designed to keep things organized.
Containers rely on something called a container engine that manages resources
and allows the container to share those resources across themselves.
So if one container isn't working too hard,
another container can take advantage of that.
One of those popular container engines is called Docker.
So if one of your IT people use the term Docker container,
then you now know what they're talking about. Now,
because containers are compartmentalized,
that makes them very portable.
Since most major cloud providers also support containers,
we can pretty seamlessly move those containers to a cloud provider and it will
run just the same as it did originally. Plus,
we can use any one of those major cloud providers to host these applications.
If we wanted to move the containers back on site in a hybrid cloud model,
we could do that too without much trouble at all.
The portability of containers is one way companies are
mitigating the vendor lock-in concern that I mentioned earlier.
So think of containers like a little backpack that holds everything you
might need to travel anywhere you want.
Lastly, I'll leave you with this.
We have really just scratched the surface of cloud architecture here.
It is a whole discipline that people spend years learning.
So if your organization does not have access to cloud architecture
experts,
I would highly recommend seeking the help of one before you start designing your
cloud based architecture. If you're not careful,
you can end up with quite a mess.