So, Fabio, the stage is yours.
I'm really looking forward to hearing about on-premise data centers.
Do not need to be a legacy.
Thank you.
So hello, everyone.
And just to be clear, this is going to be the topic that we are going to cover a little
bit of history, some less alert, and then some technology bets that I think that would make
sense in such conversation.
So about me, I have been a Linux user for 20-ish years.
I've been working with Linux for close to 20 years now, and I currently work with Reddit
and do basically similar kind of conversation in my day-to-day job.
So let's start with a little bit of history.
Of the cloud.
Let's call it this way.
So Rackspace was founded in 1998 and I think was the first company that defined itself
as cloud.
In 2005, SoftLayer was founded.
They defined themselves as bare-meta-cloud.
And then in 2006, we have the S3 launched by AWS, which was the first service of AWS.
2006 again, EC2, sorry, yeah.
And then Google App Engine arrived, IBM bought SoftLayer, creating an IBM cloud now called
and by 2021, AWS has more than 200 different services.
So what about the history of the known cloud, because what we have seen are all cloud environments,
but those are nothing new if you think about this.
So in 1964, which is probably older than anyone or most of the people in this room,
IBM introduced the CP40 and this machine had time-sharing technology, which was very different
from what we call today cloud, but still it was probably the initial point of the history
of the cloud and in the late 60s, IBM released Simon, which is an hypervisor.
By 74, the two definitions, the two kinds of hypervisor get defined as tape 1, the bare-meta
virtualization, tape 2, the hosted virtualization.
And by 1998, VMware got founded and in 2000s, majority of companies moved from bare-meta
to VMware's VMs.
2001, ESX got released, which was type 1 kind of virtualization.
2003, we have the first type 1 open source virtualization, Zen.
And still 2003, VMware introduces Vmotion, which allows you to basically move a machine
from one host to the other without rebooting it.
In 2008, Microsoft arrived with Hyper-V, it previously had some other kind of virtualization
tool, but Hyper-V got launched in 2008.
So what is the cloud?
Why we are distinguished the first group and the second one?
Wikipedia says that cloud computing is the on-demand availability of computing system
resources, especially data storage and computing power without direct active management by
the user.
So I think this is a good definition.
I think that a better definition is a business model where one party rents to a second party
computer system resources, especially data storage, cloud storage and computing power
with the smallest granularity possible.
And my point is cloud is not technical, is a business model.
And if you think about, we move from renting machines like VPS on a monthly basis, and
then AWS introduced the concept of ECU that was initially on an hourly based and then
minute and then second.
And now you can buy lambdas or similar kind of things for milliseconds.
And in a way, also CPUs had the same shrinkage.
So we move from food CPUs or sockets to vCPUs, which basically is hyper-threaded threads
to fractional vCPUs with lambdas or similar services.
So my point being, the whole thing about cloud is not technical, is only about the business
side of it.
So what can we learn from not only the last 20 years of what we can define as cloud, but
also the previous 50 of what we can define as non-cloud, and more specifically, because
we have seen that the cloud model actually works.
The non-cloud model was not very functional to the business, to the point that very often
those data centers got outsourced or in some different ways moved to the cloud in the sense
that moved to someone else, and the business started to expand constantly those machines
due to the basically OPEX model instead of the COPEX model.
So there is one big aspect that we need to remember about this, which is the separation
of concerns.
So standardize the interface between the infrastructure and the workload.
If you go in legacy data centers, very often you have 1,000 different kinds of systems
that the infra people have to provide to the workload people.
And this is because, oh, my system is different, my software is different, whatever, in the
end of the day, that is a huge load for the infrastructure part of the business.
Second, the scalability needs to be at workload level, so the infrastructure also needs to
be somehow reliable and within some SLAs, but if the system has to stay up, if the application
has to stay up, the application will have to take care about this.
And third, workload have an abstract concept of whatever is underneath it, so the physical
architecture.
They don't need to know which data center they are in or in which rack, what is the
nearby server, and so on.
The function, so we also need a functional business model for a good managed IT system.
And the first part is, as before, standardize the interface between the workload and infrastructure
so that it's easily countable and priceable.
Second, build back the infrastructure cost to the workload owners.
We have seen, at least in my definition of cloud, that we still have two parties, one
that delivers a service and the other one that consumes it and pays for it.
So it's very important to create this also internally in companies or organizations of
any kind, because this allows the infrastructure side of the business to justify their expenses
over some kind of at least recognition of revenue or whatever, cost recovery, whatever.
And third, keep the cost down.
This is a key point, AWS, Google, those companies will do everything they can to keep the cost
down because they need to be positive, cash flow positive.
Obviously, if you are a department in a company, it's slightly different, but it's very important
to still be cash flow positive because this will guarantee you that you will not have
any issues over time with this part of the financial model.
And third, maintain control.
We have seen the clouds are obsessed about maintaining control and obtaining even more
control on their hardware, their system, whatever, and this is very important for your own cloud
if you want to be able to maintain it for 10, 20, 50 years.
So the first one is, I would say, do not use, but be very cautious on using third-party
property software, those companies can go away, can change pricing model, can do whatever,
be aware of this.
Second, evaluate very strongly the buy versus build decision because when you buy, obviously
it's here now, but you don't have the know-how about this.
So probably you will want to build a lot of your systems, not the core parts, but maybe
the dashboard layer or that kind of thing so that you can effectively manage it however
you think better.
And third, be very aware of lockings because those will bite you over the course of the
years.
So how do I define the locking?
I define it as the product between the probability that a component will require substitution
during the solution lifetime and the total cost of the substitution.
So for instance, Linux, if you base all your architecture on Linux, it's going to be very
expensive to move out of Linux, but in the other hand, it's very improbable that you
will need to do it because very probably in 10, 20 years Linux will be here.
So a couple of points on technologies, the first one is keep the complexity of your system
at the lowest level possible.
Systems will get more complex and more absurd over time, so at least at the beginning start
with the simple thing possible.
Second, prefer build time complexity over run time complexity.
It's way easier to automate a build thing than to automate something to be run.
And also when something breaks, it's better if it's simple because it's easier to fix.
If you have to compile your stuff, compile it, but try to keep the complexity at the
run time at the minimum possible.
Third, minimize the amount of services that you deliver to your business or your workload's
owners so that effectively you can guarantee that those services are exactly what they
require and you are able to deliver them in a sensible way.
So I think that one big point is containers.
Delivering a container-based solution at least, it's probably the best option I think
today and user Kubernetes distribution, whatever you prefer and choose, that makes sense, it's
fine and we'll see later the Kubernetes APIs are now fairly well-known, fairly abstract
and fairly used so that those can be a good interface between the infra and the workload
side.
Also, you can do it yourself, community, call it whatever, a distribution.
You can buy a commercial distribution of Kubernetes.
If you do it, first, be sure that it's fully open source what you're buying so that you
decrease your lock-in because you are decreasing the cost that it will take you to move from
this to any other solution.
Second, from a trust-worthy company, hopefully that company that you buy it from will not
fail tomorrow because if it does, you will have bigger problem.
Enter with a long track record of not screwing their customers because it's not good.
And if they are heavily involved into the open source community, it's even better because
that means that they are driving the development and they do have all the knowledge needed
to eventually fix issues as soon as they arise.
So around automation, use an immutable approach to your infrastructure.
If you start to have different things and weird infrastructure going on, it will be
a dead sentence.
Second, version your infrastructure, GitOps is an option.
There are many others.
No matter what you do, try to have versions so that effectively you can potentially roll
back or at least see what change from a version that is known to be working to the current
one and automate the whole process.
If you have humans involved, you will have issues.
It will cost more and it will be effectively less resilient and reliable.
So putting all together what we have seen, I would suggest to first create a multi-data
center architecture so that effectively you have all that redundancy and kind of things
but hide them from your developers.
Maybe they know the region concept or they said concept but don't show their physical
layout to your users otherwise they will start to do weird stuff.
Second, use a tool to manage the clusters.
Open cluster management is an open source project that does it.
There are other projects that do similar things.
It's very, very useful and it will help you over time because probably you will end up
running many clusters.
Third, I would suggest personally to standardize on the Kubernetes APIs as the only interface
between the workload and the infrastructure because those are, as seen, very known.
Use a bare metal container platform so don't use virtualization or other stuff into it.
You will have, hopefully, enough workload to justify tons of servers, physical servers,
don't add complexity with virtualization in between.
Automate all the infrastructure pieces and configurations, obviously, as seen.
Start providing only a few interfaces to your business and then eventually extend them when
needed.
So an example would be an OCI registry, object storage and pods, deployments, those kind
of basic things.
And then if your business comes out saying, oh, we really need that, then eventually you
expand.
But the thing is, only provide new services when you are sure that there is the requirement
for it.
So, for instance, let's say that you want to do a database as a service.
You already have onboarded 100 applications, 80 of those actually use MySQL.
It would make sense to provide MySQL as a service, but it does not make sense to provide
50 different databases as a service of which 48 will never be used.
It's only complexity and cost for you.
And then create a simple UX for your users that completely obstruct everything that is
below.
So even push your Kubernetes configuration here and we will manage it.
And hopefully then you will be ensuring that all this stuff is fashion and so on so that
even when the workload fades for some reason, you can say, look, a version N minus one was
working.
You did something, now it's broken.
It's not the info.
So this was it.
Thank you.
I don't know if we have a couple of minutes for questions, no?
If there are.
Thank you for your talk.
Could you expand a bit on the, I didn't get why the, what was the advantages of building
multiple data centers at first?
So that is usually a business requirement because they will say, oh, we want to have everything
that is HA or at least this service needs to be HA and with one data center, it would
be hard.
Obviously it really depends if you are a small organization, maybe two data center, three
data center could be okay.
If you are a big organization, maybe spread throughout five, 10 legally different regions,
then you will need obviously 30, 50 data center.
That's a completely different scale.
Obviously all those are very generic suggestions and then you have to apply them to your specific
situation.
And just a quick follow-up on that, how do you hide that from the workload developer?
So the line just after that one where you say they have to not know about the multiple
clusters, how does that work?
Yeah, so if you pick AWS for instance, they have the concept of region and AZ.
Some AZ, so AZs are not data centers.
Some are data centers.
Other are parts of a data center, but different availability zones within the data center
are others are containers, in the sense of like 40 food containers full of servers.
So the user does not know.
They know that there is region X, AZ 1, 2, 3.
What 1, 2, 3 means, no one knows.
And no one cares.
And that's the thing.
Thank you for the talk.
And in your definition of locking, you spoke about cost of portability, multiply by probability
of portability.
But doesn't it like if you file to assess the probability of portability, wouldn't you
fall in a lock-in without being aware of it?
Sorry, what do you mean?
Okay, I will always run my cloud in Amazon Web Service.
Why would I need portability?
And then I start using locked-in products.
So I will never be able to leave.
Yes, well, you will be able to leave.
It's always possible to leave.
You will simply revive from scratch your whole application and you leave.
So what is the cost of that?
A billion?
Okay.
So now it becomes a billion of lock-in.
That is my point.
You can rewrite tomorrow from scratch, from the way it's up.
It's possible.
How much it will cost you?
A billion?
Five billion?
A trillion?
Okay.
That is your lock-in value.
And that's the thing.
Obviously, I would suggest you to keep the lock-in as low as possible.
So try not to re-write.
To be in a situation where you have to rewrite everything.
Thank you.
Hello, one quick question.
So if your organization has a traditional manual approach to operations, which thing
would you automate first?
I would start from very simple processes just to ensure that it works in the organization.
The organizations start to understand it, processes like create VMs or create containers,
whatever kind of thing you do, and then some things such as patching and so on.
But if you really want to go the automation way, it's way easier to, after you have tested
a little bit the thing, start to say, okay, now we have the version two of the environment
that is fully automated from day zero.
Otherwise, you will always be in a kind of automated but not completely automated situation.
Thank you.