{"id":862,"date":"2021-02-07T18:08:19","date_gmt":"2021-02-07T16:08:19","guid":{"rendered":"https:\/\/dam-evangelist.blog\/?p=862"},"modified":"2023-01-02T21:05:11","modified_gmt":"2023-01-02T19:05:11","slug":"iaas-vs-paas-vs-saas-die-cloud-modelle-im-dam-kontext","status":"publish","type":"post","link":"https:\/\/dam-evangelist.blog\/en\/2021\/02\/07\/iaas-vs-paas-vs-saas-die-cloud-modelle-im-dam-kontext\/","title":{"rendered":"IaaS vs PaaS vs SaaS – The different cloud models in the DAM context!"},"content":{"rendered":"
\"\"<\/a>
Cloud IaaS PaaS SaaS<\/figcaption><\/figure>\n

At some point, everyone comes to that point when evaluating DAM systems:<\/h4>\n

Do I want to run my DAM on premise or in the cloud?<\/h5>\n

For a lot of companies today, the cloud is the first choice, but you have to distinguish between the different cloud models:
\nIf you’ve ever spoken to a DAM vendor, I’m willing to bet that they’ve told you:
\nSure we offer our solution as SaaS (Software as a Service)<\/em>
\nIn the vast majority of cases, however, this will probably not be the case.
\nThe term SaaS has mistakenly become established as an “umbrella term” for systems that are operated in the cloud. However, SaaS is only one model that can be used in the cloud context. In fact, it is probably the least commonly offered model in the DAM context.<\/p>\n

In the following, let me first discuss the usual cloud models.<\/h4>\n
The various models can be visualised very well using the cloud pyramid:<\/h5>\n

\"\"<\/a><\/p>\n

At the bottom of the pyramid is the IaaS (Infrastructure as a Service) model.<\/h5>\n

As the name suggests, you rent the infrastructure from a cloud provider to operate your own server, for example. In practice, this means that they are usually provided with a virtual host. The virtual host uses the hardware structure\/infrastructure of the cloud provider (and sometimes the backup infrastructure etc.). You are responsible for everything else as the “tenant”.
\nThis means that you have to install your operating system, all middleware components, such as Apache web server, or PHP yourself. They also have to take care of when and if they update all their software.
\nIn this context, they themselves have the greatest control over their system. However, you also need the necessary technical know-how to be able to operate your system. In the DAM context, you could say it is an on premise installation in the cloud. On premise because they basically have to do all the steps that they would have to do if they were installing on site. They have to choose the right operating system, they have to choose the right middleware components, and they have to install and configure the right software solution. The only thing they don’t have to do is buy the hardware. In most cases, your DAM integrator will do this installation and configuration for you.<\/p>\n

Let’s move on to the middle model, PaaS (Platform as a Service).<\/h5>\n

The PaaS model goes one step further. Here you not only rent a pure VM host, but you also rent the operating system and certain middleware software that you need for your software solution.
\nOne of the big PaaS providers is Microsoft with its Azure platform. Here you can choose the operating system, web server, programming interfaces, etc. for your machine and rent them as well. The only thing you are responsible for is the actual software you want to run, in our case our DAM system.
\nThe advantage is that you no longer have to worry about many issues.
\nFor example, the OS is always kept up to date, security patches are regularly installed or deployed for the OS and middleware.
\nThe disadvantage is that you relinquish control. Some DAM solutions always “lag” a little behind the current components. For example, the DAM may not yet be compatible with PHP 8 or even RedHat 8, although these components are already used by the cloud provider. Of course, there are also possibilities to lure versions here, but you have to do this explicitly and keep an eye on it.<\/p>\n

The top of the pyramid is our old familiar SaaS model:<\/h5>\n

Software as a Service means no longer having control over OS, middleware, or software solution.
\nHere, it is usually the case that in our DAM context, the manufacturers deploy their new software cyclically in the cloud. You as an end user usually have no information about what exactly is behind the software you are using. That is, which OS, which version of the OS, which middleware components, etc. Ultimately, they no longer have to worry about updates and security patches of any kind.
\nIt can be difficult in this context if they have their own developments that dock onto their SaaS DAM system. In this case, they have to rely on the manufacturer to ensure that updates are backwards compatible, especially with regard to the interface definition. Your DAM manufacturer may also offer you the possibility of a test phase on a new updated version. As a rule, however, this is not provided for in the SaaS context! For the DAM manufacturer, SaaS offers the great advantage that there is only one current version of the software. This is of course much easier to manage and maintain than tens of different versions “floating around” on different platforms.<\/p>\n

Now the all-important question arises:<\/h4>\n

Is there one model that is best for running a DAM solution? The answer here is unfortunately, as was to be expected: NO!<\/h5>\n

For the users, it usually doesn’t matter which cloud model is used. Not every DAM manufacturer supports every cloud model.<\/p>\n

It is important to pay attention to whether the DAM is very strongly connected to other systems.
\nIf there are connections to ERP, PIM or web shops, then it can often be difficult with a pure SaaS solution due to the lack of control that one has with the SaaS model. It can then be advantageous to opt for a PaaS solution, where you at least still have control over the version of the DAM system itself. In the context of the PaaS model, you also have the option of operating a test system on which you can carry out updates and test them.
\nIn my view, classic, genuine SaaS models are mainly advantageous for very agile and partly autonomous teams. Here, the focus is on the fast and rapid further development of the DAM system. Dependencies on third-party systems are low or do not exist. In the SaaS environment, I therefore see mainly the classic BAM (Brand Management Systems) systems at the moment. Here, agile, distributed teams are working on campaigns, brand guidelines, etc. No one wants to or can deal with the technicalities of a DAM system. If there is also a lack of support from the IT department, you are very well positioned with a SaaS solution!
\nPlease feel free to contact me if you have any questions about this topic!<\/p>\n

 <\/p>\n