添加链接
link管理
链接快照平台
  • 输入网页链接,自动生成快照
  • 标签化管理网页链接

八千字長文,讀者煩請耐心收看。

今 (2018) 年 10 月 28 日,IBM 斥資 340 億美元,以溢價 63% (紅帽收購時股價 $116.68,IBM出價每股 $190)收購了 Linux 開源系統供應商紅帽 (Red Hat)。

本次交易之所以受到矚目,除了是 IBM 創立 107 年以來最大規模的一次收購案,也同時創下了美國科技業第三大併購金額的紀錄,僅次於JDS Uniphase 在 2000 年以 410 億美元收購光學元件供應商 SDL,以及戴爾和 EMC 在 2016 年 670 億美元規模的併購。

IBM 為什麼要買紅帽?

許多新聞對於此次併購案的說明都是:IBM 旨在更好地與雲端運算巨頭 Amazon、Microsoft 以及谷歌母公司 Alphabet 競爭。

但真的是這樣嗎?我的看法是,不是。IBM 收購紅帽不是為了直接與三巨頭做直接競爭,相反地、正是為了與三大雲服務供應商的合作關係。以下將為大家帶來深入淺出地事件剖析。

再也跳不起舞的大象

IBM 近年來的狀況不容樂觀,是眾所皆知的事實。

2011 年,多年來皆對外宣稱科技公司超出自己擅長的領域、而不願貿然投資的巴菲特突出奇招,大舉投資了 IBM 這家老牌的 IT 服務公司逾 100 億美元(約 2,934 億元台幣)。

這個故事的結局可能大家都聽過了,被藍色巨人關進套房,成了股神的投資生涯中為數不多但廣為人知的汙點。從 2017 年第 4 季開始,巴菲特執掌的波克夏大砍 IBM 的持股高達 94% 。在幾乎賣光 IBM 股票的同時,巴菲特選擇增持了近一倍蘋果股票。(參考 CNBC 新聞: Warren Buffett says Berkshire Hathaway has sold completely out of IBM

2017 年 2 月,多次被評為美國最佳癌症研究機構的德州大學安德森癌症中心(UT MDA)宣佈終止與 IBM 的合作關係,表示 IBM Watson 技術尚未準備好臨床使用。(該醫療中心已向 IBM 累計支付了 3900 萬美元,而這個項目最初的合約金額才 240 萬美元)

一蹶不振的高階伺服器硬體業務(低階產品線已經出售給聯想)、Watson 在商用上的重重挫敗,號稱為 IBM 下一代業務重心的雲端運算/資料中心服務又被 Amazon、Google、Microsoft 三家通吃、輪不到 IBM 排上號,種種原因直接導致了現在持續低迷的 IBM 股價。

IBM 發布截至今 (2018) 年 9 月 30 日止的第 3 季財報顯示, IBM 整體營收下滑 2.1% 至 187.6 億美元,低於市場預估的 191.0 億美元。

IBM 的系統業務(包括主機伺服器與儲存系統),營收為 17.4 億美元,銷售成長約 1%,遠低於前一季的成長 25%。認知軟體業務(包括人工智慧平台 Watson、分析和網路安全服務)的營收則為 41.5 億美元,較去年同期衰退 6%。而最具戰略指標意義的雲端業務營收 45 億美元,下滑至第二季的一半,僅年增 10%。

最新出爐的財報顯示,IBM 已中斷短暫連續成長紀錄,未來展望也蒙上一層陰影。

今 (2018) 年 4 月發生了一件事情,令 IBM 的處境雪上加霜。美國五角大廈(國防部)將雲端運算的十年期採購合約,單子全數切給 Amazon,而不若往常都是多家供應商分包完成。五角大廈選擇 Amazon 作為單一供應商的計劃受到了 IBM 與 Oracle 等雲端運算廠商的集體抗議。(參考 Bloomberg 新聞: IBM Loses Challenge to Pentagon Cloud Bid Seen Favoring Amazon

慣例作為政府、軍方與金融業等大型客戶的第一優先廠商,如今走到這一步,眾人皆知, IBM 的光環已經不再了。

開源界的奇蹟──紅帽是誰?

紅帽 Logo (Photo Credits: 紅帽官網)

作為一間販賣軟體服務的 IT 公司,如果有一天將軟體裡面的程式碼通通開放出去供人免費下載,還能夠營利嗎?比如 Microsoft 釋放出 Office 辦公系列軟體的程式碼,或 Adobe 把 Photoshop、Illustrator 等服務也都開放出來。

想想就覺得不可能、何遑這樣的一間企業能夠不只營利、還能做到上市,全球員工人數高達一萬兩千人。

但紅帽做到了。

不像 Microsoft、IBM、Adobe 這樣傳統上販售專利軟體起家的廠商,紅帽不擁有自家軟體的智慧財產權,紅帽的軟體產品都是以開放原始碼形式供人免費下載、修改、測試、使用,是全世界唯一一家做到上市的開放原始碼軟體解決方案廠商。

既然軟體都免費開放出去了,紅帽是怎麼營利的呢?

在開源的世界中,各式各樣的開源專案都有不計其數的工程師參與其中,也有打著省錢這樣如意算盤的企業想直接拿開源軟體來做使用,卻也得花更多精力研究與打包測試,甚至在遇到問題時,也無人能協助解決。

由於紅帽的工程師大量參與在開源社群的專案當中,不僅對於其中相當熟悉,更能進一步提取相關技術整合在一起,成為使用者可直接上手的商業化的產品,來作為特定的大型企業客戶解決方案。客戶無須購買軟體本身,而是以年費訂閱 (Subscription) 的方式來獲得紅帽的技術顧問服務。

過去五年來,紅帽的營收增加 81%,淨利增加 68%。2017 年度,紅帽交出營收 24 億美元的成績單,甚至喊出 2022 年時,營收預期將增加 1 倍、站上 50 億美元大關的口號。

IBM 近年來在雲端運算上的策略發展

2013 年,IBM 斥資 20 億美元收購了全球最大的未上市 IaaS 服務提供商 SoftLayer,當時 SoftLayer 擁有一萬兩千名客戶與 13 座資料中心;收購 SoftLyaer 後的 IBM 也沒有停下佈局基礎設施的腳步,2017 年為止,IBM 在全世界已經布建 55 座資料中心。

然而若觀察一下 IBM 的資本支出 (CAPEX) ,會發現一個相當不合理的結果。

Photo Credits: Platformonomics

作為一位意圖進軍雲端運算基礎設施服務市場的廠商,大力採購相關硬體來佈署資料中心絕對是必須的行為,看看 Amazon 與 Google 近年來的數字一路往上飆的 CAPEX 數字即知。

由上表可以得知,相較於 Amzon、Google 及微軟每年持續擴大資本支出,Amazon 去年更達到 200 億美金的規模,相較之下,IBM 的資本支出卻不增反減,違反常理。

這意味著,IBM 已經不想玩、或根本玩不起這個資本遊戲了。

如果不專門打 IaaS 層級,那還有什麼能做的服務項目?讓我們重新來思考一下,AWS 與 IBM 的客戶各是哪些族群。

大型客戶會選擇自建資料中心;而中小型客戶沒錢做私有化,直接租公有雲。因此 AWS、GCP 等競爭廠商的多數客戶,其實原先就不是 IBM 的主力客戶。而 IBM 原本的主力客戶,包括金融業、政府或大型企業,原先都是不會上雲的客戶類型,多數都是自建資料中心。

現在,我們可以開始思考一些問題了──IBM 如何在這波雲端運算的浪潮中獲利?IBM 真的有需要與 Amazon 等廠商同時競爭中小企業的 IaaS 層級服務嗎?

你可能可以很直覺地猜想到,IBM 當然還是會專注做原本大客戶,轉型向服務於大型企業客戶的純軟/顧問服務的公司,賣企業伺服器軟體了。

你想的沒錯,專門做伺服器上面的軟體。但什麼叫「企業伺服器軟體」?這就牽扯到了基於 Linux內核的「容器技術」(Container)。

顛覆傳統虛擬化技術的容器 (Container) 與碼頭工人 (Docker)

如果你是不清楚容器 (Container) 技術、或是不清楚容器與虛擬機 (VM) 差異的讀者,在這裡簡單的為大家科普一下,以利我們後續的討論。

想像你今天住在一間雅房中,廁所與衛浴在公共空間,代表大家都必須要共用衛浴,這是不太令人舒服的事情,畢竟每個人使用衛浴的習慣都不太一樣;因此我們決定把住處從雅房改造成套房,讓每個人在各自的房間中都有獨立的衛浴。

這個官方例子可能淺顯到令人難以覺察容器技術的厲害之處,我們換成實際案例來看──如果你的硬體上面跑了三個應用程式 (App),每個應用程式都需要各自的框架 (Framework),比如Ruby on Rails、Flask 等。然而常見的狀況是,App 1 需要的是 Ruby on Rails Version 1、App 2 需要的是 Ruby on Rails Version 2,而用 Python 編寫的 App 3 需要的是 Flask ……。不但得找空間儲存這些 App,由於 Framework 不能共用,我們還得找額外的空間儲存這些 Framework。

既然我們不能讓這些房客共用衛浴,那就改為開一個個封裝好的容器,變成輕量級的封閉環境,讓各自 App 跑在各自需要的環境裡面。

Photo Creidts: Docker Blog

就像船運業的貨櫃 (Container) 一樣,在貨櫃於 1950 年代被美國運輸大亨發明之前,鋼琴、腳踏車、蘋果、手錶、汽車等各式各樣的貨物都被放在各自的箱子裡面搬運;由於箱子規格變化多端,沒辦法用機具大規模地做搬運,導致了高額的人力成本。直到貨櫃出現後,無論什麼類型的貨物、都可以被放在統一規格的貨櫃中做封裝並搬運。

而把一個個的貨櫃 (容器) 裝箱,就是碼頭搬運工 (Docker) 的工作了。 Docker 是 2013 年,一家提供 PaaS 雲服務的公司 dotCloud 開源釋出的一套將容器技術標準化的平台。Docker 會將一個 App 使用到的程式語言函式庫、資料庫、甚至作業系統等等所有能讓這個 App 順利執行的必要環境,都包在一個自給自足的容器裡。

Docker Logo (Photo Credits: Docker官網)

Docker 利用 Linux 內核中的資源分離機制,來建立獨立的軟體貨櫃,這可以在單一 Linux實體下運作,避免啟動一個虛擬機器造成的額外負擔。要啟動一個 App,Docker 啟動該容器即可開始工作;換句話說,只要有 Docker 的地方就能啟動該容器,不用管最底層硬體與作業系統。

不若虛擬機,由於虛擬機是模擬底層硬體,裝完了虛擬機後、還得從頭開始安裝 Guest OS、建置環境,相較於容器,可謂費時耗工。

在運輸業中,貨櫃不論裝載了哪種貨物,都能允許使用船隻、火車或貨車等不同的實體來做運輸,在雲端運算的世界中,容器即是軟體部署的標準單位,開發人員只要做一點點的修改(或根本不用修改),就能輕鬆高效地跨環境進行佈署。

事實上,只要是在作業系統內建立孤立虛擬執行環境的作法,皆可稱之為容器技術,比如早在二十幾年前 Unix 系統內建的 chroot 機制,以及之前 Google 在 Linux 貢獻的 cgroups 等,也都是一種容器技術。

容器並不是一項嶄新的技術,然而為什麼一直到近年來,容器一詞才開始大紅大紫?除了硬體效能的增長與 Amazon 雲端運算服務越趨熱門之外,最重要的還是 Docker 的出現,熱門的程度讓雲端運算一夕之間似乎是與 Docker 一詞緊密的聯繫在了一起,dotCloud 甚至改了自己的公司名稱為 Docker 大舉推行。

有了 Docker 熱潮在先,開始有一堆公司開始前仆後繼的學 Docker 公司推出 Container相關技術來做商業使用,比如 Google。

稱霸容器編排管理界的 Kubernetes

Docker並不是萬能,在容器的個數越來越複雜的情況下,如何進行叢集管理將會是一大挑戰,比如:如何避免所有的資源都被單一個 Container 拿走、或根據需求提供不同的資源?此時便凸顯了 Google 所推出的開源項目──「Kubernetes」的重要性。

Kubernetes 的本意是希臘語的掌舵手,時常被簡稱為「K8S」。Kubernetes 是一個容器叢集管理系統,最主要的功能就是管理使用 Docker 建置的容器。

此前其實也有人做類似的管理系統,比如 Docker 也有自己的容器編排工具 Swarm,與加州大學柏克萊分校開發的 Apache Mesos,但是 Kubernetes 在產品成熟度方面更具優勢,同時日益壯大的開源生態系也為其加分不少。

Photo Credits: Google Blog

Kubernetes 的前身,是 Google 內部用來管理上百個資料中心、數百萬台機器的基礎架構──「Borg」大規模叢集管理系統 (Large-Scale Cluster Management)。Google 擁有巨量的資料中心,可想而知為了管理方便,必然不會是以 Native 方式來安裝系統,通常都是靠 VM/Container 的技術來進行管理,因此 Borg 涵蓋了容器管理與分散式儲存,在此前已發展了十年。對於 Google 而言,只要硬體利用率能提高幾個百分點、便能為 Google 節省下高達數百萬美元的營運成本。

或許內部使用的太過順暢,才讓 Google 直到 2013 年 Docker 大紅時,方赫然被啟發:這種基礎設施好像也能對外賣錢!

進行了一些重整後, Google 在 2015 年 3 月推出了更名後的 Kubernetes ,並把它作為一個開源項目作社群推廣散播,意欲來拉下 AWS 相關產品的獨佔性優勢。(大型 IT 企業選擇開源都是作為一種打造生態系、避免競爭對手壟斷的商業手段)

由於紅帽在 IaaS 層級上並沒有與 Google 做競爭,加上紅帽高層的高瞻遠矚,相較於其他軟體巨頭,紅帽與一家叫 CoreOS 的容器技術解決方案新創,是最早大方擁抱 Kubernetes 的雲服務商。Kubernetes 問世後的半年內,紅帽就在 2015 年 9 月推出了以 Kubernetes為基礎打造的 OpenShift 3.0 版。(OpenShift 是由紅帽公司推出的 PaaS 雲平台)

今 (2018) 年 2 月初,紅帽宣布以2.5億美元的價格收購 CoreOS ,將該公司的 Kubernetes 服務更進一步整合進自家產品,可以說目前業界最完整的企業級 Kubernetes 平台,除了 Google 、就是紅帽 OpenShift 了。現在的 OpenShift 已經成為三大公有雲巨頭 AWS、GCP 與 Azure 上的認證支援軟體。

Photo Credits: 紅帽官網

至於 AWS 這邊,由於 AWS 在 Google 推出 Kubernetes 之前,就已自己研發了ECS (Amazon Elastic Container Service);如今AWS 雖然支持Kubernetes,但礙於ECS 的存在,AWS 並沒有在Kubernetes 過多著墨,導致後面支持 Kubernetes 的態勢比其他人更晚了一步。可以說 Google 利用開源推廣,來擴大開發者與使用者社群的方式,成功反將了競爭對手 AWS 一軍──經過大量的用戶積累後,GCP 又是深度與 Kubernetes 緊密結合的服務,自然就會是大家的選擇了。

為什麼 IBM 要買紅帽?K8S 多雲/混合雲解決方案

分別為大家介紹了紅帽、容器、Docker 與 Kubernetes 的基礎背景後,現在我們終於能夠來回答這個問題了── IBM 為什麼要買紅帽?

這個問題,只有簡單一句話:IBM 現在不打算與 Amazon、Google 做基礎設施上的直接競爭了,獲益比高、同時也是自己原本的私有化大客戶群,是「多雲/混合雲」(Multi-Cloud/Hybrid-Cloud)解決方案。這時候,IBM 需要的,即是紅帽的 Kubernetes 服務。

事實上,真正的企業解決方案通常不會是公有雲,連多雲 (Multi-Cloud) 都不能百分之百地滿足客戶,尤其是政府、軍方、金融業的高度敏感資料。(這與當初 GitHub 被 Microsoft 買走時,因此發生 GitLab 逃亡潮一樣。)「多雲/混合雲」才是最終的解決方案。

比如,為了安全性考量,希望將用戶的敏感信息儲存在本地端、而其他 Web Services 就放在公有雲上面。或比如,為了成本考量,在儲存這方面,AWS的服務較為豐富(Simple Storage Service (S3)、Elastic Block Storage (EBS) 或 Elastic File System(EFS) 等多元的儲存方案是 Azure 與 GCP 難以望其項背的),因此我希望採用 AWS 的 Storage 方案,至於 Computing 方案就採用 Azure Virtual Machines。

同時,由於這些雲服務供應商的價格變動頻率很高、時不時降價,使得企業得經常對這些價格進行重新估算、選擇適當的服務重新佈署,以優化成本結構。

這裡面牽涉到的通通都是 Container 管理技術,無論是私有化佈署的資料中心或公有雲,只要是任何在標準環境中執行的應用程式,用戶完全不必變更程式碼,就能將應用隨意移植到各個硬體/作業系統平台,過程間完全無痛。

Google 將 Kubernetes 作為開源項目在經營,希望越多人用越好,藉以削弱 AWS 的服務優勢、推自家的 GCP(和 Google 將 TensorFlow 作為開源專案大力經營推廣一樣,利用開源吸引 AI 社區成員,再開始控制一切)。其他競爭廠商都知道 Google 要這樣搞,一開始絕對都不願意直接支援 Kubernetes,像是 Amzaon 也自己弄了一套自己的東西。結果 Kubernetes 太強,在開源社群蓬勃發展,現在稱霸雲端運算市場。

紅帽因為自己本來就不是與 Google 直接競爭 IaaS 服務的廠商,因此早在 2015 年 Google 推行 Kubernetes 得最一開始,大方地擁抱了 Kubernetes ,將 Kubernetes 加入自己的 OpenShift 產品裡面作為核心、今年二月又收購了 CoreOS ,現在是除了 Google 之外企業級 Kubernetes 方案中最強的。

再加上紅帽跟各大廠商的合作關係都不錯,比如紐約證交所和紅帽談系統架構合作、最後找AWS提供底層 IaaS,現在 AWS、Azure、GCP 現在都是紅帽的合作夥伴。IBM 此前也想進軍 IAAS+PaaS 市場,但由於內部嚴重不團結,部門之間各自推各自的服務,彼此間高度重疊、命名不統一、產品線紊亂。現在 IBM 想起死回生,就把腦筋動到紅帽身上了。

誰容器管理做得最好? Kubernetes。除了 Google 之外,誰 Kubernetes做最好?紅帽。

IBM 要的是紅帽在 IT 界社群經營上的名聲,包括紅帽為 OpenStack、Kubernetes、Docker 等等專案貢獻了多少可觀的程式碼與功能,尤其在 Kubernetes 僅次於 Google,現在 IBM 擁有紅帽,就有足夠的能力宣稱自己是 Native K8S Service 作為主打賣點,再加上紅帽與各家雲基礎建設服務商既有的合作關係(紅帽的中立地位讓各大廠更願意支援、原先由 IBM 在競爭關係下達成合作是不太可能的)。

不像 AWS 以中小型客戶居多,IBM 在私有雲市場原先就具備領導地位,因此更應加強原本的私有化佈署的大客戶市場,所以現在的 IBM 不打算與 IaaS 廠商做直接的競爭了──與其砸大錢去蓋大量的資料中心,不如與幾家 IaaS 供應商的關係搞好、靠他們的支援來仰賴多雲/混合雲來賣大型客戶。意味著在雲端運算的時代,無論企業客戶用的是哪家雲基礎建設供應商,都可以使用 IBM 加上紅帽提供的 PaaS 服務。

本次交易完成後,紅帽會併入 IBM 混合雲部門下以獨立單位營運,而紅帽既有的公有雲供應商的合作關係仍維持不變,包括 AWS、Azure、GCP 及阿里雲等。

在收購消息發布後,IBM 現任執行長 Ginni Rometty 表示:「收購紅帽是一項顛覆性的舉措,這將會改變整個雲端市場。IBM 將成為全球首屈一指混合雲供應商,為客戶提供獨一無二的開放雲端解決方案,幫助他們充分挖掘雲端價值,推動企業業務成長。」

為什麼紅帽要賣給 IBM?業務團隊與客戶關係

事情都是一體兩面的。IBM 買紅帽的理由很充分,然而 IBM 長久封閉官僚式的企業文化,畢竟與從開源生態圈起家的紅帽大相逕庭,融合上必定會有一大困難。為什麼紅帽要把自己賣給 IBM?

IBM 近日發展得不太好,其實紅帽也是。紅帽在 2018 年第 2 季財報顯示、本季度的銷售額在總體上低於分析師的預期。紅帽有增長、但相較於其他雲服務商的高增速比起來,紅帽的業務成長在激烈的市場競爭下已有了放緩的跡象;這也導致了紅帽股價在過去的半年間下跌了超過 30%。

紅帽旗下有豐富的企業級、雲端原生及混合雲基礎架構解決方案,然而對企業端 (to-B) 的銷售上並不只只是販售軟體這麼簡單,牽扯到了更多的售前推廣、售後支持、甚至是項目上的招投標商務關係,相較於 IBM 全球有數萬名業務人員的規模,紅帽銷售只有數千人,業務體系也不若老牌的 IBM 或 SAP、Oracle、Microsoft 這些公司成熟。

這時,你可能會想問:紅帽不也是做企業顧問服務起家的?

你說得沒錯,紅帽雖然也是做企業顧問服務起家的,但紅帽的顧問服務與 IBM 的顧問服務是兩回事。紅帽主打的是:「你使用的基本是我貢獻的開源工具,所以我有足夠的 Know-how 與 Insights 能幫你解決問題。」然而 IBM 賣的是全家桶,主打的是:「你買了我的工具後,我再對你提供顧問服務,告訴你怎麼利用它來解決你的問題。」

現在兩家合併之後,紅帽可藉由 IBM 的垂直展業知識、企業關係、服務能力,來更好地拓展自家產品的銷售範圍(尤其是 IBM 可提供交叉銷售機會),而紅帽的開源軟體可以提供 IBM 更好的產品組合去賣給企業客戶,就此達成雙贏。

未來… 收購後整併成功與否才是真正的關鍵

專利軟體的祖師爺 IBM 收購了執開源軟體牛耳的紅帽後,兩家企業是否能成功融合,才是競爭態勢上真正的關鍵。由於已經完成收購,雙方高層對於產業策略方向定已有了共識,問題就在於兩家的文化差異。

IBM 從專利封閉式軟硬體起家,已經被過去成功的經驗綁住;紅帽則是以開源商業模式為傲,內部人員對於自身的開源文化也相當驕傲。近些年來 IBM 雖然持續朝向開源邁進,然而它已被公認為是一家落後於 IT 時代的公司,其封閉官僚的作風與紅帽開放的企業文化恰恰相反。

這也是紅帽員工心生擔憂的地方。在 IBM 的管理下,紅帽還能保持初心嗎?在消息曝出之後的第一個小時內,一些紅帽員工就表示「我無法想像更大的文化衝突會是什麼樣子」、「我打算去另一家開源公司就職」、「作為紅帽的員工,幾乎所有人都更願意是由微軟來收購我們」。

雖然 IBM 發表已經聲明:紅帽將作為一間獨立的子公司運作,IBM 也不會干涉其內部運作。但以 IBM 過往的慣例而言,通常都是讓被收購方的公司獨立運作幾年後,便開始進行內部整合工作,包含組織重組以及裁員。紅帽工程師自然會考慮到這個可能性。由於這次的交易被提前發布,紅帽公司的許多工程師已經考慮離職,很可能在未來出現大規模的人員叛逃潮。

未來兩家企業要如何整合,還需要管理團隊的能力以及時間的驗證,但過程肯定會非常艱苦。有內憂有外患,IBM + 紅帽的混合雲戰略能否在未來巨頭環伺的市場下存活並取得領先地位,就讓我們拭目以待吧。

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie Duration Description
cookielawinfo-checkbox-analytics 11 months This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional 11 months The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary 11 months This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others 11 months This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance 11 months This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy 11 months The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.