Okay, welcome to the next talk.
Fabio Alessandro Fali Locati will tell us about private clouds do not need to be legacy.
A warm welcome. Let's go.
Thank you. So today we'll be look at mostly four things. First of all, what is a cloud?
Because I think it's very important to define the scope of what we are going to talk about.
Second thing is what can we learn from public clouds and we can learn lots of things from them.
They have been a very successful business model and product for the last few years.
So we can learn something from them. And then some technologies and consideration and best that you can do to have to create your own private clouds that is successful and then draw some conclusions with some more maybe names of projects that can help you.
So very quickly about me, I have been around the Linux space for the last 20 odd years and I have done a lot of public cloud work, hyperscalar work.
So I am both AWS and Google certified and I do work for Red Hat. So I also know the private cloud part as well.
So why private clouds? Because obviously for many people here it's obvious why you want to have the private cloud but why do companies also nowadays are starting to look more into private clouds as well.
So the first one is technical requirements. Public clouds, even though they seem like the perfect solution, the flexible solution for every kind of issue, actually they are hardware-sache software architecture.
So if that specific architecture does not match your workload, then maybe the public cloud is not going to be the best suited architecture for you.
Second point is legal requirement. Obviously public clouds are going to be external to your business unless you work in hyperscalar, that's a different conversation obviously for you.
But for all the others, public clouds are going to be a different company. So in some situations this is not easily done or it can be complex.
There are also financial considerations. Even though public cloud seems very cheap, you can buy everything for a few cents.
When you start to have a lot of things that maybe are running 24-7, then expenses can become higher. So there might be financial reasons to look for a different model.
And then obviously there is the most plain one, which is simply because someone in your organization decided that private cloud would be a better choice than the public one.
So let's start from the very beginning. What exactly is cloud? I started as everyone from the Wikipedia definition.
Wikipedia defines cloud computing as on-demand availability of computer system resources, especially data storage, cloud storage, or computing power without direct active management by the user.
I personally don't really like that definition. I mean obviously it's the correct definition, but I don't think it highlights the most important parts about cloud.
I prefer this one, which is mine, and I define cloud as a business model where one party runs to a second party, which could be parts of the same organization obviously.
Computer system resources, especially data storage, computing power, with the smallest granularity possible.
So the two big differences are first, the fact that I define it as a business model first, and second, the smallest granularity possible about the resources.
And if we look at the history back before it was called cloud, you used to buy servers, rent servers, better say, in either yearly or monthly basis.
Then with the cloud we moved to hours and then milliseconds, milliseconds nowadays with the functionalist things, serverless functions, and those kind of things.
So time obviously is one of those aspects at even tiner granularity, but the other one is actually resources themselves.
So before the cloud era we used to talk about CPUs or sockets or full systems. Nowadays we move to core and vcore and now fractional vCPUs.
So effectively in this way the cloud can charge every single customer exactly for the amount of resources that they are using, but most interestingly I think it's the fact that they can also have very small prices per unit because the unit is very small as well.
So what can we learn from public clouds? I think the first big bucket of things is going to be the separation of concern.
Obviously public clouds are different companies from their customers, so it's very important to define a boundary.
While in internal clouds or private clouds that is not always done. I think this is a key aspect that we need to learn from public clouds.
And to be precise they have standardized the interface between the infrastructure which is what the public cloud provides and the workload which is your part.
And by defining that clear card it's first of all easier to build, but secondly it's also easier to define which responsibilities are the provider responsibility and which responsibilities are the customer or user responsibility.
Second is the scalability at workload level. Nowadays it's I would say obvious that your application needs to be the one that scales and the infrastructure might be there or not, but the reality is that your application needs to take care about that scalability part.
Back in the days that was not obvious. Back in the days when you had more need for more resources than you had you would call your infraperson and they would provide you with a bigger server or whatever.
So I think this is an important aspect that we need to bring into a successful private cloud as well.
The third aspect is the obstruction of the physical architecture. This was a big change in the public cloud model. The public cloud was saying you don't care where my data centers are, how my server work, how many I have.
The important thing for you is you have enough resources that you can use and those are very simple kind of resources that you can use.
The second aspect that I think we should learn from them is to have a functional business model and by functional I mean economically sound business model.
So by standardizing those interfaces between the infrastructure and the workload you can actually decide a charge for them and it's easier to define what that amount of money should be if you only have very limited amount of constructs.
Now obviously if we are talking about the private cloud within a company you will not probably exchange real money internally between your departments but still you can do charge bags or virtual money, color money, whatever your company calls them.
And this is very important because having a sustainable business model means that you are not a cost center. The IT is not a cost center anymore but it is part of the rest of the company having incomes as well as costs.
Building back is critical as mentioned also for another reason because the risk of not building back is that all the other departments will look like they are absolutely in the positive even though maybe they are burning a huge amount of resources of the company.
So it's very important to build back to the final customer to ensure that their accountability is also correct.
And then the third aspect is keep the cost down. A lot of times in IT we have ignored the fact that things cost and we can justify costs only if we deliver enough value to the business.
And therefore we had a lot of cost creeping around IT, internal ITs and that was also one of the advantages that companies saw in externalized IT to public clouds or other companies because they were like okay so those people will optimize costs.
So it's very important if we want to have successful internal IT and private clouds to have them and run them in a cost aware way.
The third aspect which I think is critical to learn from public clouds is to maintain the control.
And by maintaining control I mean many different things.
So first of all set some SLOs, measure, iterate and that is a critical point.
If you don't have SLOs or SLAs or whatever different kind of indicators, objectives and so on you cannot have anything successful in the long term.
And then of course measuring iterate is very important as well.
But also it's very important to think about control in a moralistic way.
So I would say do not use third party proprietary software if it's your own proprietary software that's a different conversation.
But if it's someone else this is a big risk because when you create an architecture, a cloud for instance, you are going to host someone else workloads.
And those someone else will probably want to run the workload for a long period of time which could be 10 years, 15 years, something like that.
So you will need to ensure that you will be able to continue delivering that service for the next 10 to 15 years.
If you rely on someone else software you know it could happen a lot of different things to that software provider that can make you put you in a difficult spot.
There is also a big conversation in the IT by versus build.
So effectively every time you decided to use a software you need to decide to either buy that software from someone else or build that software.
I would say a lot of times for small tools mainly it's easier to build them than to buy them.
I mean, to buy them means that they are readily available but building them means that you do have that knowledge and that ability to then maintain that software throughout the whole life of the platform.
And then there is the big point about lockings.
Lockings can be any kind of lockings.
I do have my definition of lockings which is that lockings are the product between the probability that a component will require substitution during the life cycle of your solution which could be as I said 10, 15 more years and the total cost of that substitution.
Now lockings are not something you can walk away from because if we go very basic the Linux kernel has APIs and that APIs are a lock-in because basically if you will want to move away from the Linux kernel you will have a lot of cost if you have your whole infrastructure on it.
So obviously there is still a cost there.
What is the probability though that you will want to walk away from Linux in the next 10, 15 years or that you will need to?
Well, probably very low so I would say that is a low cost lock-in.
But in the end, you know, every single decision brings a lock-in.
You need to be aware of this and therefore manage your choices being aware of this point.
So some technologies, consideration and bets, very simple.
Let's start with the very basic one.
Keep it simple as much as possible.
Reduce the complexity of your system to a minimum.
You have to maintain that stuff for the next many, many years.
So try to keep it as simple as possible because it will become complex either way.
So better to start easy.
Second, prefer build time complexity over run time complexity.
A big example I do about this is use VMs or bare metal stuff.
I would prefer using bare metal things because obviously they are more complex to set up.
They are going to be more complex in some scaling situation as well.
But in the other hand, you will have one less layer to care about.
And when you have a lot of layers, you start to have issues just because packages or stuff goes through a lot of layers.
And it will be much harder to debug.
So effectively, if you can, move your complexity to build time rather than run time.
And then minimize the amount of services that you actually offer.
So just offer the very basic services that your customer are requiring today.
And then over time, if they will require more services, you might choose to give them as well.
But if you start today with 1,000 different services, it will not make any sense
because probably on a lot of those services, you will have very limited amount of customers.
But still, you will not be able to drop them because you do have customers
and your complexity will just skyrocket.
Second, go for containers.
Nowadays, there are still applications that are not fully containerized or containerizable.
I understand that.
But containers seems today to be a sensible unit of computing
or way of transporting application and data throughout architectures.
I would suggest going for a Kubernetes distribution.
And by Kubernetes distribution, I mean something that implements the Kubernetes APIs.
I think that Kubernetes APIs are going to be the next POSIX APIs.
So basically, the whole world will standardize on them.
And maybe there will have 10 different implementation of the Kubernetes APIs.
But still, using those Kubernetes APIs will probably be a future proof choice.
You can obviously go for a do-it-yourself installation of Kubernetes
or any other application, community one, whatever you want to call it.
Or you can go for a commercial one.
There are not that many other choices.
If you go for a commercial one, first of all, go for a fully open source one,
as mentioned before, because if you have a proprietary third-party application,
then you might incur some risk there.
Go for a trustworthy company.
And by trustworthy, I mean someone that you can trust,
because in the end, it's you that are going to deploy and work on this stuff
for the rest of the life of this application.
Therefore, you need to trust that vendor, that vendor will still be there
and support you in a sensible way.
And then third, it needs to be valuable.
And valuable is still from your perspective.
So you have to see the do-it-yourself and that specific offering that you are looking at.
Obviously, the offering will have some cost associated.
All those advantages that commercial option is giving you more or less than the DIY.
But this is a very critical choice, because then that becomes one of the key components
of your whole infrastructure.
And getting that choice wrong can be very costly in the course of the whole life of the application.
And then another suggestion from my side.
I come from an automation system administrator slash automation space.
So automation is very important for me.
First of all, go for a mutable approach to your infrastructure,
bake your images, ship the images.
When you have to do an update, just refresh the whole node with something new
that continues to work and has all the changes.
Second aspect is version everything, because hopefully you will never need to, you know,
roll back anything and rolling back is always dangerous.
But it's very important to see exactly what change from version X to version F soon
so that effective you are ready to mitigate the issues.
Then automate processes end to end.
If you don't automate a process end to end, so effectively if you have like half process automated
a human step and then half process automated afterwards,
you are not getting the majority of the advantage of the automation, which is speed and reliability,
because that human step is breaking those advantages for you.
So a few conclusions that we can do and try to put together a possible solution and stack
out of this whole conversation.
We are going to have three aspects, the infraside, the API and the workload.
So on the infraside create slash architects for multiple data centers,
even though you are not really yet using them, start to think about multi-data center deployments
because very probably you are going to need them.
Your application will want them.
Deploy Kubernetes container platforms cluster on Bermatel.
As I said, having virtual machines in between can have advantages,
but still it will give you a lot of headaches.
Use a tool to obstruct the management of those clusters.
There is open cluster management, which is a great open source tool.
You can do it with many others, pick your own, but still don't try to manage 1,000 clusters manually.
Set SLOs, measure, iterate, that is obviously a very important point,
and automate all the pieces of your infrastructure and configuration.
So on the API side, define discrete regions,
not based on technically the data centers or that kind of things,
but other reasons, that are business reasons.
One example is, for instance, legal frameworks.
Europe has a legal framework, US has a very different legal framework.
Your application owners will probably want to choose if their application is running on the US part
or the European part.
We will probably not care a lot about if the data center is in Brussels, in Ghent or wherever.
Standardize on Kubernetes APIs is the only kind of interface between your part, the infrastructure part,
and the workload, so that it's a very easy way to do it.
Start providing very, very few APIs to your user.
My example would be, for instance, an OCI registry where you would want one, object storage,
some kind of PV, PVC, so block storages,
pause deployment stage, we said, comping mask secrets,
but try to avoid databases or those kind of things,
and then when your user actually asks for them,
if you have enough users that ask for the same thing,
then you can start to add additional services.
So, on the workload side, create a simple UX to create, update, and delete workloads,
and by simple UX, I mean a UX that is simple for your users.
So, if your users are used for a certain kind of user experience,
follow whatever your users are used to.
Store every single version of your workloads configuration,
and this way, for instance, in Ghent, this way, once issues will arise and they will,
you can go back and say, look, you have changed this and that is what broke everything,
but also this will allow you to do resource tests and that kind of things on real data.
Require OCI with a knocked out if your workloads will require it,
your application to be resilient to restart, replications, migrations,
and all the other kind of operations.
If you have some application that needs to be very sticky, that's a different conversation,
but still don't put it as a default choice,
make them choose to be a special application.
So, with this, thanks a lot, and if we have question and time.
Yeah, maybe we should have time for one or two questions.
Thank you very much for the talk.
Regarding immutable applications.
Things with video, we are in some delay. Sorry for that.
Regarding immutable applications, like it's something getting thrown around a lot,
but like what exactly works to do this at scale?
Like is there any recommendation on that?
Sorry, don't catch.
Immutable applications, you recommended this,
but like as most applications are actually automated with Ansible or Puppet,
which are very mutable.
So, like what's the immutable approach?
What's the tooling there?
So, what is an immutable approach?
I would say RPMOS 3, for instance, based distributions.
So, there is Fedora, CoreOS, there is many others distribution that are doing the same thing.
If you deploy, if you have your nodes that are only running Kubernetes,
you don't need to manage them too much.
You just need a very basic operating system and then enough to run a container runner.
So, effectively, try to keep that one as small as possible, not to manage it too much,
and then use any mutable operating system such as Fedora, CoreOS.
Would be the Fedora one, there is CentOS, CoreOS, I think, or whatever it's called,
the mutable version of it.
I know that SUSE has one, Ubuntu has one as well and so on.
A question from turning from public cloud to private cloud as you describe it,
from an IT resource perspective, what does it mean for the companies who go back to private cloud?
Do they need to build up new IT, scarce IT resources?
Yeah, so from resources perspective, if the company has already dismissed all their data centers
and moved to the public cloud and now it's like, oh, maybe we should go back,
that's a little bit of a problem, but there are a lot of data centers that can rent you like square meters or racks
in their data centers, but still you would manage the whole infrastructure.
So, effectively, it just gives you space, power, and connectivity.
So, that could be a way to start doing those kind of things.
And then obviously if you have a lot of requirements, a lot of, you know, service to deploy,
you can choose which path would be the best for you.
Okay, thank you very much for the talk.
Maybe one applause? Do we have applause for you?