1 00:00:01,980 --> 00:00:05,770 Hey. Herzlich Willkommen zu einer 2 00:00:05,780 --> 00:00:10,180 weiteren Folge des To do Developer Podcasts mit Robin 3 00:00:10,190 --> 00:00:14,440 Manuel Thiel und Malte Lunchin. Wir sind nun in Folge 59 4 00:00:14,450 --> 00:00:18,680 angekommen und sprechen heute über das Thema Cloud Computing 5 00:00:18,720 --> 00:00:22,420 beziehungsweise muss man eigentlich in die Cloud oder 6 00:00:22,430 --> 00:00:25,960 wann sollte man vielleicht on premises bleiben, bevor wir in 7 00:00:25,970 --> 00:00:29,590 das Thema einsteigen natürlich erst mal vielen Dank an 8 00:00:29,930 --> 00:00:32,240 diejenigen, die uns einen Kaffee spendiert haben? 9 00:00:32,250 --> 00:00:34,270 In dieser Woche ist das der Lennart. 10 00:00:34,530 --> 00:00:38,260 Der hat 3 Kaffee für uns dagelassen, also vielen Dank an 11 00:00:38,270 --> 00:00:40,960 dich, mein davon trinke ich auch gerade deswegen. 12 00:00:42,970 --> 00:00:45,720 Herzlichen Dank an dieser Stelle von wunderbar. 13 00:00:46,130 --> 00:00:49,770 Damit können wir dann auch ins Thema einsteigen und du hast ein 14 00:00:49,780 --> 00:00:52,950 bisschen Kontext dazu, wir auf das Thema kommen ja genau und 15 00:00:52,960 --> 00:00:54,730 zwar haben wir diese Folge wieder einen Themenwunsch, 16 00:00:54,740 --> 00:00:58,450 diesmal von Daniel und Daniel arbeitet im Unternehmen, wo die 17 00:00:58,460 --> 00:01:02,050 Anwendungen auf Oracle Basis passiert und auch sehr viel 18 00:01:02,060 --> 00:01:04,510 Logik wollen diese Oracle Welt drin ist und das aber alles on 19 00:01:04,519 --> 00:01:09,760 premises ist, ändert das n bisschen Legacy gehostet ist und 20 00:01:09,930 --> 00:01:11,920 jetzt waren die anderen Microservices, um diese 21 00:01:11,930 --> 00:01:16,130 Datenbank umzubauen. Nordlichter machen mit Spring 22 00:01:16,140 --> 00:01:19,980 Boot und es tut mir leid, malte mit Gitlab und dazu dann 23 00:01:19,990 --> 00:01:23,240 Kubernetes. Und fragen sich halt so ein 24 00:01:23,250 --> 00:01:27,350 bisschen wie das Ganze in die Cloud schieben sollen, ob sie da 25 00:01:27,360 --> 00:01:29,030 überhaupt irgendwelche Mehrwerte von haben? 26 00:01:29,040 --> 00:01:32,050 Weil die Oracle Datenbank wahrscheinlich nicht mit wandern 27 00:01:32,060 --> 00:01:35,310 würde, aber wahrscheinlich doch ein bisschen Legacy, vielleicht 28 00:01:35,320 --> 00:01:38,620 ein versiert und da schon wie viel Logik drin ist. 29 00:01:38,940 --> 00:01:40,790 Jetzt haben sie intern im Unternehmen so n bisschen 30 00:01:40,800 --> 00:01:43,130 Diskussionen wie günstig ist denn das jetzt überhaupt in die 31 00:01:43,140 --> 00:01:46,330 Cloud zu migrieren? Realistisch wäre wohl eh nur 32 00:01:46,340 --> 00:01:49,170 eine Verbindung, dann weg zu Oracle Datenbank über irgendwie 33 00:01:49,180 --> 00:01:51,210 VPN oder irgendwas ähnliches netzwerktechnisch. 34 00:01:52,140 --> 00:01:55,500 Also ein bisschen die Daten on Prem lassen die Businesslogik in 35 00:01:55,510 --> 00:01:59,200 die Cloud heben und da Daniel uns geschrieben auch im Rahmen 36 00:01:59,210 --> 00:02:02,990 unserer Weihnachts Umfrage, dass er da an unserer Meinung 37 00:02:03,000 --> 00:02:05,850 interessiert wäre. Malte, was ist denn deine 38 00:02:05,860 --> 00:02:09,020 Meinung dazu? Das ist natürlich ein riesiges 39 00:02:09,030 --> 00:02:12,680 Thema und jetzt könnte man auf den spezifischen Case eingehen 40 00:02:12,690 --> 00:02:15,520 und gucken macht das in dem Fall Sinn oder nicht? 41 00:02:15,560 --> 00:02:19,570 Ich glaube ganz generell lässt sich sagen es hängt davon ab, 42 00:02:19,610 --> 00:02:23,100 was man auch als Gegebenheiten als Gegebenheiten vor Ort 43 00:02:23,110 --> 00:02:25,270 vorfindet. Sprich wenn ich meine eigene 44 00:02:25,280 --> 00:02:28,580 Infrastruktur habe und dort tatsächlich auch schon eine 45 00:02:28,590 --> 00:02:31,850 moderne Plattform drauf betreibe, die meine Anwendung 46 00:02:31,860 --> 00:02:34,680 hostet. Dann ist vielleicht der Need. 47 00:02:34,910 --> 00:02:37,980 Für eine Public Cloud Infrastruktur gar nicht so groß 48 00:02:38,020 --> 00:02:40,630 außer und das sind eher wirtschaftliche als technische 49 00:02:40,640 --> 00:02:43,010 Gründe. Es gibt die Bemühungen hier 50 00:02:43,020 --> 00:02:47,450 irgendwelche Investitionen, die man in Hardware tätigen muss, 51 00:02:47,460 --> 00:02:51,410 weil es eine Erneuerung bedarf, sich sparen möchte und 52 00:02:51,420 --> 00:02:54,370 stattdessen irgendwie in laufende Kosten übergehen möchte 53 00:02:54,380 --> 00:02:58,150 und das Ganze lieber aus der Public Cloud anmieten muss, aber 54 00:02:58,160 --> 00:03:01,350 letzten Endes technisch finde ich hängt ein bisschen davon ab, 55 00:03:01,400 --> 00:03:04,860 wo drauf läuft. Meine Anwendung und du bist ja 56 00:03:04,870 --> 00:03:07,650 auch ein ganz großer Kubernetes Fan und ein Fan von diesen 57 00:03:07,660 --> 00:03:10,940 ganzen Cloud. Kreative Technologien und die 58 00:03:10,950 --> 00:03:15,320 laufen ja letzten Endes unabhängig davon, ob ich jetzt 59 00:03:15,360 --> 00:03:18,100 meine eigenen Server irgendwo im eigenen Rechenzentrum stehen, 60 00:03:18,110 --> 00:03:21,240 hab ich die beim Dienstleister habe, ob ich die in der Public 61 00:03:21,250 --> 00:03:24,610 Cloud habe, da kann ich meine Anwendung drauf laufen lassen in 62 00:03:24,620 --> 00:03:28,340 der gleichen Art und Weise und natürlich abhängig davon, welche 63 00:03:28,350 --> 00:03:31,250 Anforderungen ich an Performance Skalierung hardwareausstattung 64 00:03:31,260 --> 00:03:34,760 habe, kann es natürlich viele Fälle geben, wo es in dem Fall 65 00:03:34,770 --> 00:03:37,420 vielleicht gar keinen Unterschied macht, sprich wenn 66 00:03:37,430 --> 00:03:40,140 ich jetzt Anwendungen wirklich in Microsofts bauen die alle. 67 00:03:40,390 --> 00:03:42,860 Zu den Containern laufen, die ich in Kubernetes betreiben kann 68 00:03:43,000 --> 00:03:45,530 und am Ende ist mir die darunter liegende Infrastruktur völlig 69 00:03:45,540 --> 00:03:47,230 egal, und das weiß ich aus eigener Hardware. 70 00:03:47,240 --> 00:03:51,950 Bereits vor Ort habe ist für mich durchaus ausreichend, dann 71 00:03:52,320 --> 00:03:55,090 mag es keinen großen Grund geben, dass in die Public Cloud 72 00:03:55,100 --> 00:03:58,290 zu verschieben außer wir wie gesagt, diese finanziellen 73 00:03:58,300 --> 00:04:00,310 Gründe wurden vielleicht irgendwie die Geschäftsführung 74 00:04:00,320 --> 00:04:02,780 entscheidet hey, bevor wir jetzt die ganze Hardware in unserem 75 00:04:02,790 --> 00:04:06,250 Data Center erneuern, stiften wir das lieber irgendwo zum 76 00:04:06,260 --> 00:04:10,120 Dienstleister in Public Cloud und Mieten, das ja Zeit 77 00:04:10,130 --> 00:04:12,180 basierend an. Und nutzen dann halt die 78 00:04:12,190 --> 00:04:14,120 Services. Von daher hängt ein bisschen 79 00:04:14,130 --> 00:04:18,420 davon ab, wo drauf laufe ich, wenn ich jetzt ganz klassisch 80 00:04:18,430 --> 00:04:21,760 irgendwie auf Infrastruktur laufe, wo ich das Ganze in WMS 81 00:04:21,769 --> 00:04:25,410 habe und dort extrem großen Managementaufwand habe, dann 82 00:04:25,750 --> 00:04:28,050 macht es natürlich Sinn, sich Gedanken über eine 83 00:04:28,060 --> 00:04:30,580 Anwendungsmodernisierung zu machen und dann im Rahmen der 84 00:04:30,590 --> 00:04:32,900 Anwendungsmodernisierung zu schauen was ist die beste 85 00:04:32,910 --> 00:04:34,220 Plattform, um das Ganze zu betreiben? 86 00:04:34,230 --> 00:04:38,110 Von daher sage ich mal die Frage lässt sich nicht so einfach zu 87 00:04:38,120 --> 00:04:39,980 beantworten, aber grundsätzlich würde ich jetzt sagen Nein. 88 00:04:41,630 --> 00:04:45,600 Niemand muss in die Cloud, aber in vielen Bereichen kann es gute 89 00:04:45,610 --> 00:04:50,220 Gründe dafür geben und neben den generellen Betriebsmodellen 90 00:04:50,230 --> 00:04:53,070 meiner Anwendung mag das natürlich auch im Rahmen der 91 00:04:53,080 --> 00:04:55,610 Anwendungsmodernisierung der Fall sein, wenn ich darüber 92 00:04:55,620 --> 00:04:57,730 nachdenke, in Richtung Plattformservice Dienste zu 93 00:04:57,740 --> 00:05:00,230 gehen und bestimmte Dinge nicht mehr in eigenen Services 94 00:05:00,240 --> 00:05:03,670 irgendwie in Containern laufen zu lassen, egal ob die anderen 95 00:05:03,680 --> 00:05:06,960 selber geschrieben ist oder irgendwie ne open Source 96 00:05:06,970 --> 00:05:09,520 Komponente kommerzielle Komponente ist, sondern ich 97 00:05:09,560 --> 00:05:10,860 setze auf Plattformen als Servicedienste. 98 00:05:12,120 --> 00:05:14,350 Die sich viel leichter managen lassen, aber die gleiche 99 00:05:14,360 --> 00:05:18,270 Funktionalität bieten und halt auch beliebig skalierbar sind 100 00:05:18,380 --> 00:05:20,790 und die mir dann die Möglichkeit geben, auch Kapazitäten 101 00:05:20,800 --> 00:05:24,850 freizugeben, die ich vielleicht für andere Dinge sinnvoll nutzen 102 00:05:24,860 --> 00:05:27,440 kann. Ein Beispiel, was mir jetzt 103 00:05:27,450 --> 00:05:30,710 kürzlich untergekommen ist, ist das Thema Monitoring. 104 00:05:30,750 --> 00:05:32,830 Natürlich kann ich jetzt irgendwie für das ganze 105 00:05:32,840 --> 00:05:36,350 anwendungs Monitoring irgendwelche Events Dienste in 106 00:05:36,360 --> 00:05:38,610 meiner eigenen Infrastruktur betreiben irgendwelche Kafka 107 00:05:38,620 --> 00:05:41,740 Cluster, die extrem viel Power brauchen, weil natürlich da. 108 00:05:42,020 --> 00:05:44,980 Tausende von Informationen pro Sekunde reinkommen je nach Größe 109 00:05:44,990 --> 00:05:47,250 meiner Anwendung. Wenn ich das ganze jetzt 110 00:05:47,260 --> 00:05:49,590 irgendwie in Richtung eines Paars Services in der Cloud 111 00:05:49,600 --> 00:05:52,920 migriere ich plötzlich wieder Kapazitäten frei an Hardware. 112 00:05:52,930 --> 00:05:55,130 Ich brauche die Infrastruktur nicht managen und habe die 113 00:05:55,140 --> 00:05:58,510 gleiche Funktionalität und am Ende ist es irgendwo einen Data 114 00:05:58,520 --> 00:06:01,210 Lake, wo meine Daten hieß eigentlich völlig egal. 115 00:06:01,400 --> 00:06:05,850 Von daher lässt sich diese Frage nicht generell beantworten, aber 116 00:06:05,860 --> 00:06:09,060 aus meiner Sicht und da würde mich deine Meinung interessieren 117 00:06:09,100 --> 00:06:13,810 nein, in die Cloud muss niemand. Ja, man muss auch dazu sagen, 118 00:06:13,820 --> 00:06:15,670 dass natürlich jetzt das Unternehmen, was Daniel hier 119 00:06:15,680 --> 00:06:18,250 vorgestellt hat, ja eigentlich schon guten Mittelweg geht, ne 120 00:06:18,260 --> 00:06:21,040 also das ist ja so ein bisschen, wenn die sagen, die nehmen quasi 121 00:06:21,050 --> 00:06:24,600 schon Kobane dies und bauen da gerade Microservices mit Spring 122 00:06:24,610 --> 00:06:28,160 Boot also beides sehr moderne Technologien dann würd ich sagen 123 00:06:28,170 --> 00:06:31,310 dann haben sie ja so ne eigene Cloud Plattform innerhalb ihres 124 00:06:31,320 --> 00:06:34,910 Rechenzentrums gebaut, denn ich finde man muss nutzen und wie 125 00:06:34,920 --> 00:06:37,530 auch nicht unterscheiden haben wir irgendwo einfach 126 00:06:37,540 --> 00:06:40,070 irgendwelche Server stehen und die muss jemand pflegen und 127 00:06:40,080 --> 00:06:42,980 warten oder haben wir inhouse vielleicht sogar die Skills? 128 00:06:43,050 --> 00:06:44,330 Also ich finde vielmehr ist Skill. 129 00:06:44,340 --> 00:06:48,060 Frage haben wir es vielleicht sogar Skills, ein kombiniertes 130 00:06:48,070 --> 00:06:50,280 Cluster oder mehrere Companies Cluster zu betreiben? 131 00:06:50,450 --> 00:06:52,840 Denn das ist nicht simpel, also companies, das richtig zu 132 00:06:52,850 --> 00:06:56,510 betreiben ist anstrengend ist Arbeit, ist sehr komplex und 133 00:06:56,520 --> 00:06:58,970 herausfordernd. Aber wenn es dann da einmal 134 00:06:58,980 --> 00:07:01,630 steht und vielleicht von einem anderen Team bereitgestellt 135 00:07:01,640 --> 00:07:04,210 wird, was sich darauf spezialisiert hat, als das Thema 136 00:07:04,220 --> 00:07:08,230 dann nachher nutzt, dann hat das Entwicklerteam ja wahrscheinlich 137 00:07:08,240 --> 00:07:10,480 sogar eine sehr ähnliche Experience zu dem, was sie in 138 00:07:10,490 --> 00:07:13,520 der Cloud vorfinden würden, nämlich dass sie einfach nur PI 139 00:07:14,010 --> 00:07:17,160 interagieren und deswegen finde ich auch man kann ja so Cloud 140 00:07:17,170 --> 00:07:19,310 native Technologien da gerade gesagt. 141 00:07:19,920 --> 00:07:23,140 Auch. Jetzt schon mal nutzen, also 142 00:07:23,150 --> 00:07:26,750 namentlich Container, Kubernetes und sowas und damit ja sehr 143 00:07:26,760 --> 00:07:29,980 ähnliche Experience erzeugen. Ich würde mir die Frage halt 144 00:07:29,990 --> 00:07:33,730 immer auf Skill Level stellen haben wir inhouse die Skills das 145 00:07:33,740 --> 00:07:37,110 zu betreiben, weil sonst ist es glaube ich sehr komfortabel. 146 00:07:37,120 --> 00:07:40,470 Das andere Cloud Provider abzugeben, haben wir wie du auch 147 00:07:40,480 --> 00:07:42,570 richtig hat. Das Ergebnis von den Kosten her 148 00:07:42,580 --> 00:07:44,550 Sinn ne, ich hab ja nicht nur die Hardware kosten. 149 00:07:44,560 --> 00:07:46,950 Ich habe auch Stromkosten. Ich hab ja Miete für ein 150 00:07:46,960 --> 00:07:49,080 Rechenzentrum ich personal was pflegen muss. 151 00:07:50,900 --> 00:07:52,950 Und kann nicht und das finde ich immer ganz wichtig, dass nicht 152 00:07:52,960 --> 00:07:56,010 ausgelassen wird, kann ich auch die Sicherheit, die Security in 153 00:07:56,020 --> 00:07:59,870 meinem eigenen Rechenzentrum gewährleisten, zu einem Grad, 154 00:07:59,880 --> 00:08:01,950 den meine Anwendung benötigt oder zu einem Grad, den ich 155 00:08:01,960 --> 00:08:04,530 sonst in der Cloud kriegen würde, weil natürlich absolute 156 00:08:04,540 --> 00:08:10,900 Experten bei Microsoft, AWS, Google, Oracle, SAP und Digital 157 00:08:10,910 --> 00:08:13,580 Ocean und so weiter arbeiten, natürlich nichts anderes machen 158 00:08:13,590 --> 00:08:16,850 als ihre eigene Cloud Infrastruktur zu testen. 159 00:08:17,960 --> 00:08:20,410 Und wenn ich diese Fragen alle für mich zufriedenstellend 160 00:08:20,420 --> 00:08:21,830 beantworten kann, würde ich dir auch zustimmen. 161 00:08:21,840 --> 00:08:24,430 Muss nicht in die Cloud. Ich kann natürlich so ein 162 00:08:24,440 --> 00:08:27,080 hybrides Modell fahren, wo ich sage ich rede Ihr Kopf war, ich 163 00:08:27,090 --> 00:08:29,630 profitiere von der Rechenpower, die mir in der Cloud sehr easy 164 00:08:29,730 --> 00:08:31,680 in Anführungszeichen zur Verfügung gestellt wird. 165 00:08:31,690 --> 00:08:36,200 Lass meine Daten on Prem und die verbinden sich entweder VPN 166 00:08:36,210 --> 00:08:38,280 Tunnel oder die meisten Cloud Provider bieten wir auch dann 167 00:08:38,289 --> 00:08:40,840 an, dass ich wirklich quasi eine Netzwerkverbindung anlege. 168 00:08:40,850 --> 00:08:44,380 Also ich kenne das ja expressrouten wirklich mehr oder 169 00:08:44,390 --> 00:08:46,960 weniger virtuell Kabel zusammengesteckt, sodass ich 170 00:08:46,970 --> 00:08:48,970 dann direkt Verbindung in die Cloud bekomme. 171 00:08:48,980 --> 00:08:49,770 Über meine Telekommunikationsprovider, denn 172 00:08:49,780 --> 00:08:52,960 ich muss natürlich aufpassen. Immer so m Hybriden. 173 00:08:53,950 --> 00:08:55,560 Modell, das nicht zum Bottleneck wird. 174 00:08:55,570 --> 00:08:57,500 Dass ich da nicht irgendwie meine hochperformanten 175 00:08:57,510 --> 00:09:01,130 Anmeldungen habe und die immer eine sehr langsame Verbindung in 176 00:09:01,140 --> 00:09:06,150 meine on Prem Daten aufbauen. Aber wenn ich eh schon auf so 177 00:09:06,160 --> 00:09:08,330 modernen Technologien und die Skills habe, würde ich dir 178 00:09:08,340 --> 00:09:12,420 zustimmen da muss niemand in die Cloud, aber du dachtest gerade 179 00:09:12,430 --> 00:09:15,060 das Thema Computer in die Cloud schieben. 180 00:09:15,470 --> 00:09:17,610 Ich glaube wenn ich an einem Punkt bin, wo ich solche 181 00:09:17,620 --> 00:09:21,300 Microservices in Containern habe und die Skills habe einen 182 00:09:21,310 --> 00:09:25,070 Kubernetes Cluster zu betreiben, dann macht es vielleicht am 183 00:09:25,080 --> 00:09:28,130 wenigsten Sinn, Computer in die Cloud zu schieben, sondern es 184 00:09:28,140 --> 00:09:30,440 macht vielleicht mehr Sinn, andere Dienste in die Cloud zu 185 00:09:30,450 --> 00:09:33,680 statt zu schieben, die vielleicht nicht so leicht zu 186 00:09:33,690 --> 00:09:36,280 betreiben sind. In dieser Containerwelt weil 187 00:09:36,370 --> 00:09:39,220 natürlich gehört einiges dazu, zum Beispiel ein Datenbanksystem 188 00:09:39,230 --> 00:09:44,380 oder n Storage System in so einem Cluster zu betreiben. 189 00:09:44,390 --> 00:09:46,620 Und vielleicht macht es gerade bei diesen Dingen Sinnrichtung 190 00:09:46,630 --> 00:09:50,580 passt Services zu gucken und zu sagen OK, ich mach mir jetzt gar 191 00:09:50,590 --> 00:09:52,520 nicht die Arbeit zu verstehen, wie ich meine Datenbank 192 00:09:52,530 --> 00:09:55,310 Technologie in Kubernetes Cluster betreibe, das 193 00:09:55,320 --> 00:10:00,280 entsprechend persistent und sicher und Backups et cetera PP 194 00:10:00,290 --> 00:10:03,640 sondern ich gehe halt mit meiner Storage Technologie oder mit 195 00:10:03,650 --> 00:10:06,570 meiner Datenbank. Gehe in die Cloud und mach halt 196 00:10:06,680 --> 00:10:11,230 on Prem weil ist eh da Hardware mach ich halt Computer, das 197 00:10:11,240 --> 00:10:13,950 heißt, ich kann vielleicht auch zu geringeren Kosten meiner 198 00:10:13,960 --> 00:10:16,340 Anwendung betreiben, weil die Hardware vielleicht schon 199 00:10:16,350 --> 00:10:18,370 abgeschrieben. Ich hab dann letzten Endes zwar 200 00:10:18,560 --> 00:10:21,030 die Operationskosten um das Ganze zu managen zu betreiben, 201 00:10:21,040 --> 00:10:24,970 fortgesetzt die Skills sind da, aber letzten Endes sind das dann 202 00:10:24,980 --> 00:10:27,860 halt die Personalkosten, die Stromkosten, die Kosten für die 203 00:10:27,870 --> 00:10:30,430 für das Rechenzentrum im Sinne eines Standorts. 204 00:10:30,440 --> 00:10:32,930 Aber ich muss die Hardware nicht mehr einkaufen und dann muss man 205 00:10:32,940 --> 00:10:34,450 die Rechnung machen ist es günstiger? 206 00:10:35,030 --> 00:10:38,890 Wirklich Prominente irgendwie Computer aus der Cloud zu kaufen 207 00:10:38,900 --> 00:10:42,020 oder die eigene Hardware einfach so lange weiter zu betreiben, 208 00:10:42,030 --> 00:10:46,260 bis sie den Geist aufgibt und bei ganz vielen Anwendungen die 209 00:10:46,270 --> 00:10:49,930 Halt in der Cloud laufen, sieht man halt auch so n so n 210 00:10:49,940 --> 00:10:53,770 kontinuierlichen keinen kompletten Schiffen die Cloud, 211 00:10:53,780 --> 00:10:55,650 sondern wird nach und nach immer mehr Cloud geschoben, 212 00:10:55,660 --> 00:10:58,630 insbesondere zu den Zeitpunkten, wo vielleicht auch harmonisiert 213 00:10:58,640 --> 00:11:00,950 werden muss. Und es spricht ja nichts dagegen 214 00:11:01,190 --> 00:11:04,330 Hardware die ich im Data Center habe einfach noch so lange wie 215 00:11:04,340 --> 00:11:07,750 möglich so effizient wie möglich auszunutzen und ich finde gerade 216 00:11:07,760 --> 00:11:11,030 Computer ist. Dafür ein super Ansatz in Form 217 00:11:11,040 --> 00:11:13,930 von so einem Kubernetes Cluster, was sich dann auch auf alter 218 00:11:13,940 --> 00:11:16,850 Hardware laufen lassen kann und da halt meine Anwendungen dann 219 00:11:16,860 --> 00:11:18,870 in Form von Services drauf skalieren kann. 220 00:11:19,320 --> 00:11:21,460 Ja finde ich einen sehr guten Punkt hast du natürlich völlig 221 00:11:21,470 --> 00:11:23,500 recht. Das Thema Computer ist ja 222 00:11:23,760 --> 00:11:27,300 eigentlich gelöst ich mein Computer ist das die Simplere 223 00:11:28,220 --> 00:11:32,250 Nutzungsweise von meiner Hardware vor allem sowas wie 224 00:11:32,260 --> 00:11:34,230 Kubernetes löst dann ja auch Themen wie Hochverfügbarkeit 225 00:11:34,240 --> 00:11:37,350 zumindest innerhalb eines eigenen Rechenzentrums. 226 00:11:38,660 --> 00:11:42,680 Weil einfach, wenn irgendwie n Server ausfällt, dann kann das 227 00:11:42,690 --> 00:11:46,080 Handeln und natürlich völlig recht so ne Hardware 228 00:11:46,090 --> 00:11:48,840 Hochverfügbar zu betreiben und dann auch noch regelmäßig 229 00:11:48,850 --> 00:11:51,700 Backups zu ziehen und sowas nicht h Datenbank schöne 230 00:11:51,710 --> 00:11:54,200 Datenbank verfügbar zu betreiben, regelmäßig Backups zu 231 00:11:54,210 --> 00:11:57,440 ziehen, vielleicht während zu verteilen, Daten dazwischen zu 232 00:11:57,450 --> 00:12:00,470 synchronisieren zwischen verschiedenen Nodes, das ist 233 00:12:00,480 --> 00:12:02,970 natürlich deutlich komplexer, nochmals irgendwie Container 234 00:12:02,980 --> 00:12:06,160 irgendwo zu hosten und das natürlich auch Gedanken, die mir 235 00:12:06,170 --> 00:12:08,410 abgenommen werden hilft das natürlich nichts. 236 00:12:08,900 --> 00:12:10,830 Bei denen ist klar die Oracle Datenbank, die bleibt 237 00:12:10,840 --> 00:12:14,440 wahrscheinlich Bremen und immer, wenn ich so edel fahre, muss ich 238 00:12:14,450 --> 00:12:16,160 natürlich dieses Bottleneck angucken. 239 00:12:17,080 --> 00:12:20,380 Und eine Frage, die mir gerade eben während du gesprochen hast, 240 00:12:20,390 --> 00:12:22,750 also einen Gesichtspunkt, der gerade auch während du 241 00:12:22,760 --> 00:12:24,530 gesprochen hast, mal aufgefallen ist natürlich. 242 00:12:25,120 --> 00:12:27,330 Nicht nur die Skills und so da sind, sondern sich auch mein 243 00:12:27,340 --> 00:12:29,980 Rechenzentrum natürlich hinterfragen muss, ob es die ja 244 00:12:29,990 --> 00:12:32,280 aber Performance und verfügbarkeitsanforderungen 245 00:12:32,290 --> 00:12:37,010 erfüllt, die ich brauche. Höre ich gerade sowie Milch s 246 00:12:37,020 --> 00:12:40,150 vielleicht einhalten muss? Was ist denn einmal gibt? 247 00:12:40,160 --> 00:12:42,680 Dann gibt es einen Single Stromkabel Wanderer stolpern 248 00:12:42,690 --> 00:12:45,550 kann oder was ist denn mein Telekommunikationsprovider? 249 00:12:45,560 --> 00:12:49,640 Mein Internet ist die Anwendung dann oder vielleicht mehrere 250 00:12:49,650 --> 00:12:52,380 Standorte verteilt, wenn ich dann Anforderungen für habe, 251 00:12:52,390 --> 00:12:55,580 sind das natürlich auch die Cloud wahrscheinlich mit wenigen 252 00:12:55,590 --> 00:12:58,220 Klicks zu meistern sind, als wenn ich die Haare selber bauen 253 00:12:58,230 --> 00:13:00,870 muss, aber wahrscheinlich ist es auch in dem Beispiel von Daniel. 254 00:13:02,080 --> 00:13:05,280 Jetzt nicht unbedingt ratsam, da auf Teufel komm raus in die 255 00:13:05,290 --> 00:13:08,670 Cloud zu migrieren und ich glaube ein ganz wichtiger 256 00:13:08,680 --> 00:13:11,060 Aspekt, über den man auch sprechen muss ist, dass viele, 257 00:13:11,070 --> 00:13:14,040 wenn sie an Cloud denken, natürlich an Hyper Scaler, 258 00:13:14,050 --> 00:13:17,780 Public Cloud denken und wenn man sich tatsächlich anschaut, wie 259 00:13:17,790 --> 00:13:20,930 viele große Unternehmen es machen und das sehe ich in 260 00:13:20,940 --> 00:13:24,020 meinem Arbeitsalltag ganz viel, dann werden halt auch Dinge aus 261 00:13:24,030 --> 00:13:27,390 dem eigenen Data Center, welches nicht Cloud Ready ist, weil man 262 00:13:27,400 --> 00:13:30,520 nicht über die Skills verfügt, weil dort die Services nicht zur 263 00:13:30,530 --> 00:13:33,660 Verfügung stehen. Das Ganze zu einem Dienstleister 264 00:13:33,670 --> 00:13:36,100 gegeben wird. Der mir eine private Cloud zur 265 00:13:36,110 --> 00:13:38,380 Verfügung stellt, basierend auf einem bestimmten 266 00:13:38,390 --> 00:13:41,800 Technologiestack und gerade wenn man dann standardisiert auf so 267 00:13:41,810 --> 00:13:44,640 Sachen wie eine bestimmte Datenbanktechnologie oder zum 268 00:13:44,650 --> 00:13:46,580 Beispiel Kubernetes als Betriebsplattform für meine 269 00:13:46,590 --> 00:13:49,260 Computer, dann kann man natürlich auch solche Private 270 00:13:49,270 --> 00:13:51,960 Cloud oder Dienstleister Clouds verwenden. 271 00:13:51,970 --> 00:13:55,600 Von daher ist es vielleicht auch kein Schwarz weiß ich betreibe 272 00:13:55,610 --> 00:13:58,320 die Hardware selber im eigenen Rechenzentrum oder ich gehe 273 00:13:58,330 --> 00:14:01,090 irgendwie zu einem der großen Hyper Scaler, sondern es gibt 274 00:14:01,130 --> 00:14:03,340 natürlich auch einen Weg dazwischen, wo man einige der 275 00:14:03,350 --> 00:14:05,960 Benefits nutzen kann, aber vielleicht nicht alle Benefits 276 00:14:05,970 --> 00:14:08,830 der Cloud. Wie zum Beispiel die ganzen Pass 277 00:14:08,840 --> 00:14:11,130 Dienste, das merkt man immer wieder, wenn man bei vielen 278 00:14:11,140 --> 00:14:13,250 Diensten mal im Detail reinschaut, die sich Cloud 279 00:14:13,260 --> 00:14:16,290 nennen, dann findet man halt ganz viele, die bieten mir 280 00:14:16,300 --> 00:14:18,690 irgendwie Compute Storage Datenbanken, aber dann hört es 281 00:14:18,700 --> 00:14:21,990 halt auf und wenn ich mir den Service Katalog, von der Google 282 00:14:22,000 --> 00:14:23,740 von Amazon von der Microsoft angucke. 283 00:14:24,530 --> 00:14:26,720 Einfach, wie viele Plattformen Dienste ist da? 284 00:14:26,730 --> 00:14:29,880 Mittlerweile gibt es für jeden Use Case gibt es einen und das 285 00:14:29,890 --> 00:14:32,340 macht die Sache so schwer, teilweise auch mehrere Dienste, 286 00:14:32,350 --> 00:14:35,030 die ich alternativ verwenden kann und dann verstehen muss, 287 00:14:35,070 --> 00:14:37,980 was jetzt der beste Dienst für meinen Use Case ist in meinem 288 00:14:37,990 --> 00:14:41,130 Anwendungsszenario, wenn ich den dann erstmal in meine Anwendung 289 00:14:41,140 --> 00:14:43,580 eingebaut habe, ich auf der einen Seite zwar die 290 00:14:43,590 --> 00:14:46,500 Abhängigkeit haben, aber viel mehr Komfort für den Betrieb, 291 00:14:46,510 --> 00:14:48,910 weil ich mich auch ganz viele Dinge nicht mehr kümmern muss, 292 00:14:48,950 --> 00:14:51,460 um die ich mich kümmern müsste, selbst wenn ich das zu einem 293 00:14:51,470 --> 00:14:54,730 Cloud Dienstleister geben würde, der vielleicht nicht einer 294 00:14:54,740 --> 00:14:59,810 dieser Hersteller ist. Ja, hab ich n ganz spannenden 295 00:14:59,820 --> 00:15:02,400 Fall und Artikel noch zu mitgebracht, der ist mir wieder 296 00:15:02,410 --> 00:15:06,610 eingefallen, als ich hier in den letzten Tagen die für die das 297 00:15:06,620 --> 00:15:09,100 Feedback aus der Weihnachtsfolge aufgearbeitet habe und hier als 298 00:15:09,110 --> 00:15:13,260 Kommentar getreten bin und zwar hathey.com. 299 00:15:13,950 --> 00:15:18,040 Angekündigt im Oktober letzten Jahres, dass sie aus der Cloud 300 00:15:18,050 --> 00:15:22,100 gehen, also dass sie quasi die Cloud verlassen werden und gibt 301 00:15:22,110 --> 00:15:24,350 einen spannenden Artikel. Den verlinken wir auch in den 302 00:15:24,360 --> 00:15:28,420 Shops kann ich sehr empfehlen zu lesen und wer das nicht kennt o 303 00:15:28,430 --> 00:15:32,620 com ist gegründet von Thirty Seven Signals. 304 00:15:32,830 --> 00:15:35,590 Das ist das Unternehmen rund um David Heinemeier. 305 00:15:35,600 --> 00:15:38,920 Hanson weiß nicht, ob dem jedem ein Begriff ist, im Internet, 306 00:15:38,930 --> 00:15:42,590 auch bekannt unter seinem Handel, die H auf Twitter auch 307 00:15:42,600 --> 00:15:45,590 relativ. Meinungsstark und polarisierte 308 00:15:45,600 --> 00:15:48,580 auch irgendwie gerne mit irgendwelchen Meinungen und ist 309 00:15:48,590 --> 00:15:52,700 halt Journals, die machen Basecamp, das ist so ne ja 310 00:15:52,710 --> 00:15:55,390 kollaborationssoftware für n bisschen bekommen. 311 00:15:55,400 --> 00:15:57,670 Mittlerweile hat kommen das ist ein alternativer Email Service, 312 00:15:57,680 --> 00:16:00,030 der mit Emails n bisschen anders umgeht, eigentlich relativ cool 313 00:16:00,040 --> 00:16:06,250 und ist der Gründer von Ruby on Rails und der hat in einem Blog 314 00:16:06,260 --> 00:16:09,010 Post als CT in dieser Rolle geschrieben, dass sie die Cloud 315 00:16:09,060 --> 00:16:10,660 verlassen, weil es eigentlich nie. 316 00:16:13,680 --> 00:16:16,730 Weil sie in der Cloud irgendwie so richtig diese Benefits 317 00:16:16,740 --> 00:16:19,210 bekommen haben, die sich damals versprochen haben und zwar 318 00:16:19,220 --> 00:16:24,030 schreibt er in seinem Artikel als Zitat wirklich Ranking 319 00:16:24,040 --> 00:16:27,790 Computers is mostly a bad deal for medium sized companies like 320 00:16:27,800 --> 00:16:32,170 ours with stable growth the savings promised in reduce 321 00:16:32,180 --> 00:16:36,590 complexity never materialized the we make our plans to leave 322 00:16:36,600 --> 00:16:40,670 übersetzt Computer zu mieten ist meistens finanziell schlechter 323 00:16:40,680 --> 00:16:43,820 Deal für so mittelgroße Unternehmen. 324 00:16:43,890 --> 00:16:47,430 Wie ihr es vor allem Unternehmen, die relativ stabil 325 00:16:47,840 --> 00:16:50,850 Wachstum haben oder die relativ stabile Auslastung haben, und 326 00:16:50,860 --> 00:16:54,450 dann schreibt er weiter die Einsparungen, die wir durch die 327 00:16:54,490 --> 00:16:56,950 durch die Komplexität durch verringerte Komplexität und sie 328 00:16:56,960 --> 00:16:59,870 haben sich nie wirklich gezeigt, also werden wir die Cloud 329 00:17:00,440 --> 00:17:05,190 verlassen und er schreibt das nicht ganz spannend, dass es 330 00:17:05,200 --> 00:17:08,310 eigentlich nur 2 Gründe dafür gibt, in die Cloud zu gehen und 331 00:17:08,319 --> 00:17:12,940 er sagt entweder ist meine Apps so simpel, dass ich komplett auf 332 00:17:12,950 --> 00:17:14,690 Managed Services setzen kann, oder? 333 00:17:14,760 --> 00:17:17,900 1 Managed Service komplett ausreicht sowas wie heroku App 334 00:17:17,910 --> 00:17:21,579 das gemacht hat oder ich weiß, wie das geht irgendwie.com die 335 00:17:21,589 --> 00:17:24,000 haben auch einen sehr einfachen Text, wo ich einfach aus meinem 336 00:17:24,089 --> 00:17:26,940 Repository raus deployen kann mir dann irgendwie 1 5 337 00:17:26,950 --> 00:17:29,850 Datenbanken aussuchen n bisschen Hosting Technologie ist auch 338 00:17:29,860 --> 00:17:34,270 sehr cool Service, aber meine ist so simpel, dass diese Folie 339 00:17:34,280 --> 00:17:35,710 managed Services komplett ausreichend. 340 00:17:36,740 --> 00:17:40,050 Oder der zweite Grund ist, dass meine Last, die auf meinem 341 00:17:40,060 --> 00:17:45,650 Service sitzt, meine Peaks so. Irregulär sind und so 342 00:17:45,660 --> 00:17:48,660 unterschiedlich sind, dass ich halt von diesen 343 00:17:48,700 --> 00:17:50,500 Skalierungseffekten, die ich in der Cloud habe, enorm 344 00:17:50,510 --> 00:17:53,970 profitiere, dass irgendwie auf Knopfdruck mir 10 2000 Server 345 00:17:53,980 --> 00:17:56,610 dazubuchen kann in meinem Cluster, die am nächsten morgen 346 00:17:56,620 --> 00:17:58,710 alle wieder verschwunden sind, nicht nur für die paar Minuten 347 00:17:58,720 --> 00:18:01,410 bezahle, wo ich die hatte ich sehr dynamisch auf Lastspitzen 348 00:18:01,420 --> 00:18:03,360 reagieren kann, wo ich vielleicht auch Services 349 00:18:03,370 --> 00:18:05,920 Anwendungen auf 0 runter skalieren kann und sowas also 350 00:18:05,930 --> 00:18:10,090 wirklich so wilde Peaks in deiner Usage hast und was was 351 00:18:10,100 --> 00:18:14,960 David Hanson das schreibt ist. Hey für die meisten 352 00:18:14,970 --> 00:18:17,990 Applikationen draußen gilt beides nicht also die meisten 353 00:18:18,000 --> 00:18:20,370 Applikationen, vor allem die, die die, die die Schreiben, also 354 00:18:20,380 --> 00:18:23,480 Basecap und hat, kommen da sagt er das gilt für uns gar nicht, 355 00:18:23,490 --> 00:18:26,200 weil wir haben eigentlich eine sehr Predictive, sehr 356 00:18:26,210 --> 00:18:28,640 vorhersehbare Last auf unseren Services. 357 00:18:29,160 --> 00:18:31,540 Wir müssen gar nicht so wild hoch und runterskalieren ständig 358 00:18:31,550 --> 00:18:34,710 jetzt irgendwie schon am Black Friday auf einmal ganz, ganz, 359 00:18:34,720 --> 00:18:37,000 ganz viel Luft. Und selbst wenn es Black Friday, 360 00:18:37,010 --> 00:18:38,850 kommt es auch nicht unvorhergesehen. 361 00:18:39,670 --> 00:18:42,220 Unsere App ist aber komplex genug, dass wir eben nicht mehr 362 00:18:42,230 --> 00:18:44,320 einzelnen Managed Service, sondern irgendwie auch über 363 00:18:44,330 --> 00:18:47,000 Pflaster. Verteilt unsere Lösungen hosten 364 00:18:47,620 --> 00:18:50,520 und deswegen sagen sie aus der Cloud, denn sie hätten dafür die 365 00:18:50,530 --> 00:18:54,340 Skills im Team. Und wollen halt wieder ihre 366 00:18:54,350 --> 00:18:58,070 eigenen Rechenzentren betreiben oder ich ganzer Ihren Stacks, 367 00:18:58,580 --> 00:19:02,380 weil es günstiger sein soll. Und das fand ich eigentlich 368 00:19:02,390 --> 00:19:06,060 relativ relativ spannenden Ansatz ich habe eine Meinung zu, 369 00:19:06,070 --> 00:19:08,640 aber ich würde gerne hören, wie du darüber denkst, dass die 370 00:19:08,650 --> 00:19:10,550 quasi jetzt von der Cloud wieder weg migrieren. 371 00:19:11,270 --> 00:19:14,680 Ja, ich kann das absolut nachvollziehen, was dort in dem 372 00:19:14,690 --> 00:19:17,880 spezifischen Fall die Gründe sind und kann auch sagen OK. 373 00:19:17,890 --> 00:19:20,730 Für dieses Unternehmen mag es die richtigen Entscheidungen 374 00:19:20,740 --> 00:19:23,200 sein. Generell finde ich aber und ich 375 00:19:23,210 --> 00:19:26,840 finde das super zusammengefasst. Generell finde ich aber da wird 376 00:19:26,890 --> 00:19:30,740 absolut vereinfacht, also ganz viele Aspekte werden auf die 2 377 00:19:30,750 --> 00:19:33,570 Punkte auf die 2 technischen Punkte runtergebrochen gesagt, 378 00:19:33,580 --> 00:19:35,110 wenn diese beiden nicht auch zutreffen. 379 00:19:35,400 --> 00:19:38,310 Macht eine Cloud oder eine Public Cloud für euch keinen 380 00:19:38,320 --> 00:19:40,390 Sinn? Aber es stehen tatsächlich in 381 00:19:40,400 --> 00:19:43,060 dem Artikel noch weitere Nebenbedingungen drin, die 382 00:19:43,070 --> 00:19:45,380 letzten Endes gar nicht mehr in die Betrachtung genommen werden 383 00:19:45,620 --> 00:19:49,270 also er sagt Halt auch für Unternehmen mittlerer Größe mit 384 00:19:49,280 --> 00:19:51,500 stabilem Wachstum. Das sind auch weitere 385 00:19:51,510 --> 00:19:53,460 Nebenbedingungen. Das heißt wenn ich jetzt kein 386 00:19:53,470 --> 00:19:56,520 Unternehmen mittlerer Größe mit stabilem Wachstum und stabil 387 00:19:56,560 --> 00:19:59,950 stabilem Revenue Stream bin, dann gelten halt viel mehr 388 00:19:59,960 --> 00:20:03,600 Bedingungen und ich glaube, wenn ich jetzt hingehe und sage wie 389 00:20:03,610 --> 00:20:07,230 viele Unternehmen gibt es? Die mittlere Größe, stabiles 390 00:20:07,240 --> 00:20:11,690 Wachstum, stabiles Einkommen, zusätzlich eine Anwendung, die 391 00:20:11,700 --> 00:20:16,780 weder simpel, nämlich komplex noch mit irregulären Work 392 00:20:18,020 --> 00:20:21,090 Workloads ist, also sprich keine Peaks hat. 393 00:20:21,200 --> 00:20:23,970 Dann sind wir plötzlich bei relativ wenig Anwendungen auf 394 00:20:23,980 --> 00:20:26,510 die letzten Endes diese Schlussfolgerungen, die er hier 395 00:20:26,520 --> 00:20:29,230 raus zieht auch noch zutreffen, sprich wenn ich jetzt ein 396 00:20:29,240 --> 00:20:32,680 Unternehmen bin, welches zum Beispiel sich gerade gründet, 397 00:20:33,020 --> 00:20:34,840 dann habe ich gar nicht die finanziellen Mittel, eigene 398 00:20:34,850 --> 00:20:37,720 Infrastruktur aufzubauen. Das heißt, ich muss in den 399 00:20:37,730 --> 00:20:39,940 Bereich reingehen, wo ich Computer und andere 400 00:20:39,950 --> 00:20:42,410 partyservices Miete und on the go bezahlt, weil ich gar nicht 401 00:20:42,420 --> 00:20:46,170 das Kapital habe, wenn ich jetzt nen großer Konzern bin, dann 402 00:20:46,730 --> 00:20:49,870 muss ich vielleicht einfach aus buchhalterischen gründen, weil 403 00:20:49,880 --> 00:20:51,750 ich börsennotiert bin und ich möchte hier irgendwie 404 00:20:51,760 --> 00:20:54,550 finanzoptimierungen vornehmen, dann möchte ich vielleicht von 405 00:20:54,560 --> 00:20:57,540 Capital expenses ich kaufe viel Hardware, investieren viel 406 00:20:57,550 --> 00:20:59,960 Infrastruktur und schreibe das im Laufe der Zeit ab. 407 00:20:59,970 --> 00:21:03,760 Auf operating expenses switchen, wo ich halt jeden Monat gewisse 408 00:21:03,770 --> 00:21:05,520 Kosten für meine Infrastruktur habe. 409 00:21:07,230 --> 00:21:10,130 Und vielleicht möchte ich auch Personal reduzieren, weil das an 410 00:21:10,140 --> 00:21:11,460 der Börse irgendwie besser ankommen. 411 00:21:11,470 --> 00:21:13,870 Deswegen möchte ich den Betrieb meiner Infrastruktur, eine 412 00:21:13,880 --> 00:21:16,610 Dienstleister oder in die Public Cloud auslagern, weil ich 413 00:21:16,620 --> 00:21:19,850 vielleicht börsennotiert bin und ich glaube, da gibt es dann so 414 00:21:19,860 --> 00:21:23,340 viele Bedingungen, die dann auch noch zutreffen müssen. 415 00:21:23,380 --> 00:21:26,070 Neben diesen 2 technischen, die du gerade geschrieben hast, dass 416 00:21:26,080 --> 00:21:29,210 am Ende die Anzahl der Unternehmen und Anzahl der 417 00:21:29,220 --> 00:21:32,770 Anwendungen auf denen auf die diese Schlussfolgerung hey, ich 418 00:21:32,780 --> 00:21:36,830 geh in die eigene Infrastruktur wirklich zutreffen, sehr gering 419 00:21:36,840 --> 00:21:39,180 ist. Der Personal hatten sie etwas 420 00:21:39,190 --> 00:21:40,680 zugesagt? Nee, also Personal meinten Sie 421 00:21:40,690 --> 00:21:44,130 ja, wir haben im Team die Skills, das selber zu managen. 422 00:21:44,140 --> 00:21:47,260 Das könnten die Leute, die unsere Plattformen gemeldet 423 00:21:47,270 --> 00:21:50,330 haben und die sagen wir sind so mehr oder weniger in Full Stack 424 00:21:50,340 --> 00:21:54,990 Entwicklern und da finde ich, aber fehlt mir auch ein Gedanke 425 00:21:55,000 --> 00:21:57,250 und das ist mir auch ein Gedanke, der mir gerade 426 00:21:57,260 --> 00:21:59,580 einfällt, ebenso n bisschen bei der Diskussion von Daniel wie 427 00:21:59,590 --> 00:22:02,820 ihn haben und den Rest irgendwie Cloud oder im eigenen 428 00:22:02,830 --> 00:22:07,030 Rechenzentrum betreiben wollen haben und das ist für mich immer 429 00:22:07,040 --> 00:22:08,710 das kommt für mich aber auch also was. 430 00:22:08,780 --> 00:22:11,420 Ganz oft bei dieser Diskussion außer 8 gelassen wird klar kann 431 00:22:11,430 --> 00:22:13,640 man das alles selber betreiben und vielleicht hat man sogar die 432 00:22:13,650 --> 00:22:16,440 Skills im Unternehmen muss keine Leute irgendwie dafür heiern 433 00:22:16,450 --> 00:22:19,270 oder andere oder andere Stellen streichen. 434 00:22:20,520 --> 00:22:23,110 Aber ich finde, das kommt von Opportunitätskosten nicht hin, 435 00:22:23,560 --> 00:22:26,500 weil wenn ich jetzt wirklich was habe, was in der Cloud einfach 436 00:22:26,510 --> 00:22:29,470 vielleicht einfacher ist oder schneller aufzusetzen ist. 437 00:22:30,130 --> 00:22:32,640 Dann können die Leute, die ich vielleicht habe, das ja 438 00:22:32,650 --> 00:22:34,340 theoretisch könnten ja in der Zeit. 439 00:22:35,210 --> 00:22:38,000 Features entwickeln oder was anderes bauen oder irgendwie ein 440 00:22:38,010 --> 00:22:40,480 Unternehmen nach vorne bringen und ich finde, das ist immer, 441 00:22:40,490 --> 00:22:43,530 was sich in so einer Diskussion ja auch noch betrachten muss, 442 00:22:43,660 --> 00:22:46,940 selbst wenn ich das könnte und wenn es kostentechnisch ja 443 00:22:46,950 --> 00:22:49,320 vielleicht sogar gleich auf oder vielleicht sogar günstiger als 444 00:22:49,330 --> 00:22:51,540 die eigene Hardware zu anzuschaffen, wenn ich mir das 445 00:22:51,550 --> 00:22:54,440 in der Phase nehmen Unternehmen leisten kann ich sehr gut von 446 00:22:54,450 --> 00:22:57,170 dir als da kann ich jetzt natürlich nicht dafür viele 447 00:22:57,210 --> 00:23:00,490 1000€ irgendwelche Server hinstellen, möchte vielleicht 448 00:23:00,500 --> 00:23:02,840 nochmal probieren oder werden möchte. 449 00:23:03,800 --> 00:23:05,560 Also muss ich noch in der richtigen Phase meines 450 00:23:05,570 --> 00:23:08,680 Unternehmens sein, aber was ich natürlich auch in der Cloud 451 00:23:08,770 --> 00:23:12,500 einfach spare an Zeit, bis ich das ganze Mal aufgesetzt habe, 452 00:23:12,850 --> 00:23:15,680 das sind ja auch Opportunitätskosten und 453 00:23:15,690 --> 00:23:18,850 Potenziale, die finde ich da einfach häufig übersehen werden 454 00:23:19,450 --> 00:23:22,670 und dazu kommt halt, dass das vielleicht auch etwas verkürzt 455 00:23:22,680 --> 00:23:26,140 dargestellt ist, weil letzten Endes, wenn sie über und Brems 456 00:23:26,150 --> 00:23:28,410 sprechen, sprechen sie vielleicht gar nicht da drüber, 457 00:23:28,450 --> 00:23:30,880 ein eigenes Rechenzentrum zu betreiben, weil dann brauchst du 458 00:23:30,890 --> 00:23:33,460 nicht nur die Leute, die vorher den Cloud Service gemanagt haben 459 00:23:33,470 --> 00:23:35,610 die Manager. Jetzt ein paar Server und 460 00:23:35,620 --> 00:23:38,690 Kubernetes Cluster nein, du brauchst Leute, die mit einer 461 00:23:38,700 --> 00:23:41,510 Sackkarre rex durch die Gegend schieben. 462 00:23:41,520 --> 00:23:44,690 In physikalischen Räumen und Kabel ziehen und 463 00:23:44,700 --> 00:23:47,990 Netzwerkarchitekturen designen und das ist ne ganz andere 464 00:23:48,000 --> 00:23:50,670 skillset du kannst jetzt also, wenn ich dich jetzt bitte mal 465 00:23:50,680 --> 00:23:54,170 ein großes Rechenzentrum aufzubauen, wo du wirklich die 466 00:23:54,180 --> 00:23:56,020 Kabel ziehen muss und unterbrechungsfreie 467 00:23:56,240 --> 00:23:59,250 Stromversorgung netzwerkanbindung an den telco 468 00:23:59,260 --> 00:24:03,020 Provider Failover zweite location ich sehe das Halt so 469 00:24:03,030 --> 00:24:06,540 ein bisschen auch. Bei meinem Arbeitgeber, was wir 470 00:24:06,550 --> 00:24:09,990 da teilweise für Spezialistinnen und Spezialisten haben, die sich 471 00:24:10,000 --> 00:24:14,590 wirklich mit solchen Themen Redundancy und Failover disaster 472 00:24:14,600 --> 00:24:17,240 Recovery auseinandersetzen. Ich hab mir letztens mal den das 473 00:24:17,250 --> 00:24:20,000 Network Design angeguckt, da gibt es einen Network Design 474 00:24:20,010 --> 00:24:23,040 Team, die setzen sich halt wochenlang hin und machen 475 00:24:23,050 --> 00:24:26,760 irgendwelche Skizzen, wie sie halt die Server untereinander 476 00:24:26,810 --> 00:24:30,820 verdrahten, damit halt die bestmögliche Performance in dem 477 00:24:30,830 --> 00:24:32,950 Datenbank Cluster gewährleistet ist. 478 00:24:32,990 --> 00:24:36,050 Und ich glaube die wenigsten Unternehmen haben diese Skills, 479 00:24:36,060 --> 00:24:38,340 das heißt am Ende gehst du dann wieder zu einem Dienstleister, 480 00:24:38,350 --> 00:24:42,200 der das für dich. 8 und wenn man Dienstleister dann Cloud nennt, 481 00:24:42,470 --> 00:24:45,610 bist du trotzdem mit, der kann nicht premises ne und da hatten 482 00:24:45,620 --> 00:24:48,600 wir vorhin gesprochen also wenn mir jemand das komplette Data 483 00:24:48,610 --> 00:24:52,220 Center Operations abnimmt, bis hinzu dem Punkt wo ich da nur 484 00:24:52,230 --> 00:24:54,200 noch ein Betriebssystem auf der Hardware laufen lasse und alles 485 00:24:54,210 --> 00:24:57,240 andere macht jemand anders nicht dann wirklich jemand der On Prem 486 00:24:57,250 --> 00:24:59,380 alles selber betreibt oder bin ich jemand, der in der Cloud 487 00:24:59,390 --> 00:25:00,760 ist? Ja finde ich eigentlich sehr 488 00:25:00,770 --> 00:25:04,420 schöne Zusammenfassung sowie der Server in meinem Keller sein 489 00:25:04,800 --> 00:25:09,260 wahrscheinlich nicht, wenn ich das Team habe mir wirklich ein 490 00:25:09,270 --> 00:25:11,680 Rechenzentrum. Ein paar gut konfigurierte 491 00:25:11,690 --> 00:25:14,000 Server Racks hinzustellen, bin ich wahrscheinlich einer der 492 00:25:14,010 --> 00:25:16,290 wenigen glücklichen Unternehmen, die können dann cool. 493 00:25:17,100 --> 00:25:19,530 Aber das hast du auch eingangs gesagt es muss ja vielleicht 494 00:25:19,540 --> 00:25:24,410 auch nicht immer ein Hyper scaler wie oder Azure sein Nee 495 00:25:24,460 --> 00:25:26,840 also man kann sich ja auch mal wie kleinster anschauen. 496 00:25:26,850 --> 00:25:29,410 Es gibt sowie Digital Ocean, die tolle Developer Experience 497 00:25:29,420 --> 00:25:31,950 haben, die auch deutlich weniger Services haben, die auch Cloud 498 00:25:31,960 --> 00:25:34,900 sind oder man kann doch einfach super günstig vielleicht zu 499 00:25:34,910 --> 00:25:37,280 einem Anbieter hetzner oder sowas geben sich da einfach ein 500 00:25:37,290 --> 00:25:41,790 Server mieten, die wo ne Aspekte die du genannt hast 501 00:25:41,800 --> 00:25:44,360 Netzwerktechnisch wo das schon vorkonfiguriert ist, wo ich 502 00:25:44,370 --> 00:25:46,740 natürlich auch deutlich günstiger als bei so einem Hyper 503 00:25:46,750 --> 00:25:49,190 scaler bin. Und dann, darauf kann ich mir 504 00:25:49,200 --> 00:25:51,860 immer noch mein Computer installieren, auch irgendwie 505 00:25:51,870 --> 00:25:55,320 sehr viele mittelwege ja gehen, bis man sich da wirklich sein 506 00:25:55,330 --> 00:25:58,160 eigenes Server irgendwo hinstellt versus ich gehe zu 507 00:25:58,170 --> 00:26:00,500 einem Y nee, dafür wahrscheinlich dann 508 00:26:00,510 --> 00:26:02,340 verhältnismäßig viel Geld irgendein Cluster. 509 00:26:03,040 --> 00:26:05,540 Und wenn man da die Opportunitätskosten, die 510 00:26:05,550 --> 00:26:09,050 Security und die redundancy Betrachtung nicht außer 8 lässt, 511 00:26:09,220 --> 00:26:13,250 dann kann man auf der Basis, glaube ich eine sehr gute, ja 512 00:26:13,260 --> 00:26:16,690 educated decision treffen und da irgendwie eine Entscheidung für 513 00:26:16,700 --> 00:26:21,070 sich rausholen also ich glaube, zusammenfassend lässt sich sagen 514 00:26:21,230 --> 00:26:25,140 man kann es nicht so über Vereinfachen und sagen, nur für 515 00:26:25,150 --> 00:26:27,960 die wenigsten lohnt sich die Public Cloud. 516 00:26:28,000 --> 00:26:30,470 Ich glaube, es gibt ganz viele Use Cases, wo es durchaus Sinn 517 00:26:30,480 --> 00:26:34,090 macht, wirklich auch von Anfang an dazu arbeiten und auch 518 00:26:34,100 --> 00:26:35,950 langfristig darauf seine Architektur. 519 00:26:36,020 --> 00:26:37,780 Aufzubauen. Es gibt aber auch viele Fälle, 520 00:26:37,790 --> 00:26:39,680 wo es nicht zutrifft. Von der lässt sich die Frage 521 00:26:39,690 --> 00:26:43,230 muss man in die Cloud? Ganz klar mit Nein beantworten 522 00:26:43,630 --> 00:26:47,260 und die Frage, ob man im eigenen Data Center oder bei einem 523 00:26:47,270 --> 00:26:51,080 Dienstleister bleiben kann, muss kommt, glaube ich immer auf den 524 00:26:51,090 --> 00:26:53,460 Einzelfall an. Sehr schön, dann hoffe ich 525 00:26:53,470 --> 00:26:56,020 Daniel, dass wir deine Frage damit n beantwortet haben und 526 00:26:56,030 --> 00:26:58,720 das auch spannende Diskussion, dass wir nochmal über Hey 527 00:26:58,730 --> 00:27:02,730 denfall.com und sowas gesprochen haben Fach. 528 00:27:03,560 --> 00:27:06,790 Also fand auch ne n guten Eindruck von dir das vielleicht 529 00:27:06,800 --> 00:27:09,260 sollte vielleicht mal gar nicht unbedingt auf Computer gucken. 530 00:27:09,270 --> 00:27:12,180 Das ist so ein bisschen bis sich da meistens draufschaue, sondern 531 00:27:12,190 --> 00:27:16,270 vielleicht auch die die Data Services oder irgendwelche 532 00:27:16,280 --> 00:27:19,060 Message Broker und sowas anguckt die ja wirklich komplett zu 533 00:27:19,070 --> 00:27:23,140 betreiben sind, wenn man denn sich Hybrid aufstellen möchte. 534 00:27:24,470 --> 00:27:28,310 Ist das generell was, was ihr da draußen, also unsere 535 00:27:28,320 --> 00:27:31,700 Zuhörerinnen und Zuhörer, was euch beschäftigt, oder eine 536 00:27:31,710 --> 00:27:34,750 Frage, die völlig klar ist uns doch gerne wissen könnt ihr uns 537 00:27:34,760 --> 00:27:38,230 gerne, wenn ihr uns dann nicht über Twitter oder linkedin 538 00:27:38,240 --> 00:27:40,670 öffentlich irgendwie zu schreiben wollt, wenn ihr Fragen 539 00:27:40,680 --> 00:27:42,960 oder eine Meinung zu haben, dann auch gerne über die E Mail 540 00:27:42,970 --> 00:27:46,670 Adresse, die unten verlinkt ist. Ansonsten wäre die Folge 541 00:27:46,710 --> 00:27:49,950 gefallen hat, dann freuen wir uns natürlich immer darüber, 542 00:27:50,360 --> 00:27:53,300 wenn ihr uns auf den Podcast Plattformen bewertet, auf den 543 00:27:53,310 --> 00:27:56,180 ihr unterwegs seid oder uns einen Kaffee spendiert. 544 00:27:56,190 --> 00:27:58,450 Das könnt ihr auch machen. Wir haben bei mir Coffee Link da 545 00:27:58,460 --> 00:28:02,170 unten mal verlinkt und da freuen wir uns sehr, wenn ihr uns n 546 00:28:02,180 --> 00:28:05,530 Kaffee da lasst und wenn ihr den to do Developer Podcast noch 547 00:28:05,540 --> 00:28:08,290 nicht abonniert habt, macht das gerne entweder auf Apple 548 00:28:08,300 --> 00:28:12,730 Podcasts oder Spotify und wir freuen uns dann, wenn ihr auch 549 00:28:12,740 --> 00:28:15,680 bei der nächsten Folge in 2 Wochen wieder mit dabei sein. 550 00:28:15,960 --> 00:28:19,480 Bis dahin habt eine gute Zeit, schreibt ganz viel Code und hab 551 00:28:19,490 --> 00:28:21,650 ne gute Woche ciao bis dann.