Here's what you'll learn in the webinar
More and more business-critical applications are being created in public clouds or are being moved there. With cloud solutions for companies and software from the cloud for digital collaboration, global concepts can be implemented very easily. Companies are now realizing how important it is to have an end-to-end online strategy - this applies not only to marketing portals, but above all to online stores, service portals and communication platforms with customers, partners and employees. Many companies need to upgrade. The demand for IT services is increasing, as are the issues surrounding compliance, corporate governance and security. The webinar explains the possibilities of cloud application management and what should be considered at the beginning of a project. This is because it is usually only later that you discover that public clouds offer no or only very poor SLAs for some services. diva-e offers 24/7 application management in line with the customer's requirements.
Watch online now (German only)
Jetzt Webinarfolien downloaden:
Transcript of the Webinar: Cloud Solutions - Secure Cloud Solutions with Service
Welcome and introduction
Angela Meyer: Well, good afternoon everyone and welcome to today's webinar on Cloud Solutions - Secure Cloud Solutions with Service. Thank you for your participation and I'm happy to welcome you to our webinar today. I'd say we'll wait another minute or two, because we've got a few stragglers coming in one by one. (30 sec.) So, the number of participants that is steadily increasing. That looks good. (11 sec.) And I welcome you here to today's webinar on cloud solutions. I'd say we'll just start with a technology checkup. Sascha, would you like to click on?
Sascha Sauer: Like this.
Angela Meyer: Exactly. (4 sec.) So once again, welcome to today's webinar on Secure Cloud Solutions with Service. (4 sec.) And so that we can also make sure that you can all hear and see us, it would be great if you could give us a sign and write a short hello in the right question box, whether the technology is working. (5 sec.) That looks good. We get a lot of hellos, they are looking forward to the webinar. Yes, then I would say that it works great and we start. Exactly. We'll start with a short round of introductions. Feel free to click on again briefly. (10 sec.) Exactly. My name is Angela Meyer. I'm your moderator today. I've been part of the diva-e marketing team for about four years, and I'm in charge of our webinars and events. And now I'm looking forward to getting input from our cloud expert Sascha Sauer. That's right. I'm going to turn the floor over to you and I'm looking forward to your input.
Sascha Sauer: Yes. Thank you very much, Angela. My name is Sascha Sauer. I'm the founder and CEO of diva-e and I've been an Internet pioneer from the very beginning. Since 1994, I have been involved with the Internet, Internet applications and everything that goes with them. Today's topic is the cloud. Cloud is on everyone's lips. And the question is: What is actually behind it? For large companies, for enterprises, for medium-sized companies with a global footprint, what is actually behind the cloud that needs to be considered? I myself have a degree in business informatics. That's why I'm only technically fit to a limited extent, and my view is more from the management perspective, from the organizational perspective on these things. And that's why we're going to talk a lot about services, about service level agreements and about gaps that we've found again and again in contracts. And basically want to draw attention here to what you need to consider when you go to the cloud with your application. I've brought you some slides on this and I would go through those slides first. After that, if you have questions, you can ask questions via the chat function and Angela can then pass those questions over to me at the end as well.
Angela Meyer: I'd be happy to. Yes.
Public vs. private cloud
Sascha Sauer: I have brought a study here. It's about public cloud and private cloud. These are the global spendings that are forecast here into the future. And what I would like to draw your attention to here is that we see that at least in the foreseeable future, the spendings for public cloud and private cloud will far exceed the spendings for traditional hardware hosting. What's also particularly interesting is that the two will be about the same size, at least that's the forecast. Brief classification: public cloud are classically the so-called hyperscalers or also the I say providers that appear worldwide to offer cloud infrastructure. The big ones are certainly Microsoft with Azure, then Amazon with the Amazon Web Service and Google with the Google Cloud. Alibaba would still have to be mentioned, but also IBM, SAP and some other companies, not least Face-Force operate their own cloud systems, which they also offer as public cloud. With private cloud. By private cloud we mean cloud systems which are operated individually for enterprises, i.e. which are created to meet the requirements of enterprises and also only operate in the context of the enterprise itself, but which are based on cloud solutions, i.e. which contain cloud paradigms, cloud methods. That's actually how you have to look at it. And why does this market look so interesting? We have a study here on the breakdowns of the big three private cloud providers by customer group. And I've done my own research, the review-last business year. I've put that in here as well, so you have an idea of what revenues are being made by the companies here as well. So that's Amazon, Microsoft, and Google. And as you can see here, these are definitely considerable revenues that were achieved by the three competitors in this area in the last fiscal year. And what you can also see here is that of course the distribution between large companies and small companies is very different. Generally speaking, Microsoft has a much stronger business focus. Much stronger on, yes, office software for a long time, therefore of course has a thick footprint with medium-sized and large companies.
Microsoft probably has a customer relationship with every company in the world, and you can see that here in the application distribution. Microsoft certainly has the largest share of enterprise and mid-market here, companies up to 1,000 employees, they are very well positioned. The others are, I'd say, not bad either. Amazon is certainly an innovator in the whole area and has by far the most customers. Amazon is always a little bit ahead when it comes to technology. They always develop the services and the small tools that are needed in the cloud first. And it takes a while for Microsoft to follow suit. Google is certainly very interesting for developers and clearly addresses a market. With, let's say, very good development tools, Google is addressing a market that doesn't necessarily seem suitable for enterprise companies. You have to be a bit careful here. We also know some large companies that are out in this area and have gone to the Google cloud solutions there. Overall, you have to say that for the German market, the Azure offering is probably the most attractive. I'll also come back to an assessment between these three cloud providers in the public cloud space later on. (4 sec.)
The cloud is fashionable, but what is actually behind it? What do people expect from the cloud? Why are applications going to the cloud? Why do managers love IT-managers, CEOs, CIOs-why do they love the cloud?
And here, of course, there are a few points to mention from the outset: First and foremost, flexibility. The cloud is extremely flexible. We can install systems very quickly. We can expand systems very quickly. And we can take them down again just as quickly. That's a promise, of course. There are new paradigms behind it. It's a promise that every manager certainly likes to hear. Then there is the issue of scalability and globality. Essentially, it's about the fact that even if I get more traffic, if I get more customers, if business models run upwards, I can scale very quickly and also with, let's say, simple methods. And also the global rollout, that's often the biggest problem with classic hosting variants. The global rollout is very simple, is very modern in design. I can roll out and deploy applications around the world in a very short time. And accordingly offer the service I want to provide to my customers on the Internet in all regions of the world. In addition, there are two key points why managers opt for the cloud: First, Consumption of Service: We see a lot of innovation happening in the cloud today. One example is a service, let's say translation service. Translation service was a big issue for many years. Now, with translation services in the public clouds, you can actually consider that largely solved.
In other words, language barriers are virtually non-existent if you're smart about how you use the applications. In other words, I consume such a service, which is also being further developed in the cloud and which naturally thrives on the fact that many people in the cloud also use this service. As a result, it is getting better and better. Alexa is on everyone's lips. I think you know what I'm talking about here. It's just one example. There are many, many other examples of services: Machine learning, AI, these are all topics that are developing. That's also what this is about. In principle, these innovations will also take place in the cloud in the future, and that of course also promises efficient use of future services in the cloud. That is also an essential decision: Why should I move a system to the cloud or implement a new system in the cloud? However, there are also some disadvantages that the cloud brings with it. First and foremost: the cloud is not necessarily cheap. All the advantages: Flexibility, scalability, and so on, I have to pay a fair amount of money for. If you compare that, you could say that a classic hosting system, which comes without flexibility and without these advantages-. If I compare that with a system operated in the cloud, which also does not use these advantages, it would probably be more than twice as expensive if I operate it in the cloud. The other way around, you can also see that the cloud providers give very strong discounts for fixed rented cloud consumption or competition, let's say in the range of 70, 80 percent on their normal cloud prices. You can see a little bit in that: Flexibility, scalability, that costs money. Accordingly, some of our customers are actually paying five-figure sums every month to the respective public cloud vendors for relatively manageable, complex, but relatively manageable systems. Some public clouds have data security issuances. Those are mentioned over and over again. A lot has been done by the cloud providers. There is a lot that can be done, especially in the private cloud area, but you have to take care of it. You can't just take it for granted. You have to be proactive and apply the corresponding things as they are offered. It's not all out-of-the-box, but you have to take care of it. The same topic would be corporate governance.
Many systems in this area violate the corporate governance that companies have given themselves. This is about handling data, handling confidential data, what are data secrets, company secrets, and where can data be stored. Data protection also plays a role here, and compliance with data protection laws must be taken into account. Here, too, there is a field of work in which a lot has happened, but here, too, there are always those who have reservations and who, of course, rightly register some restrictions in the complete use of cloud systems. You have to think of it like this: If I use a translation service that is available in the public cloud, then data is of course transported to the Internet, to the cloud, is translated there if necessary, is analyzed if necessary, and is returned in a translated manner. Now you can already imagine: It is difficult to understand what really happens with this data. At this point, as I said, be careful what services you really use. And then, of course, there is the issue of service level agreements. I once wrote here about weak-or-no service level agreements. This is also a point that I would like to go into in more detail. We see a great need for action here at the moment.
What do I have to do when I go to the cloud?
Of course, I have to make my applications ready, regardless of whether it is an existing application or an application that I am currently creating or designing. I have to make the cloud ready. That means that monolithic systems often have to be disassembled in order to achieve cloud scalability or flexibility. And the question is always: To what extent can I split up monolithic systems or structure new systems so that they scale as well as possible? That's a definite consulting project that I'm looking at here. And the trade-off is simply always: How strongly can I position myself independently of the cloud systems? What do I want to develop and keep as my own asset in the application? Or to what extent do I want to use cloud-specific system architecture? This is also primarily about the services that I, yes, want to consume. It's nice that services help me, but if I can't take all the parameters into account, for example, governance or security issues, I've just said that. If I can't consider all of them for a specific service or a corresponding SLA is not met, I might have to solve services also independently from the cloud, even though I run it in the cloud. That is a consulting task. This is where I need to go in with a cloud expert, need to create a cloud architecture or get advice on how to create a cloud architecture. Otherwise, I run the risk of ending up with a relatively expensive system that is in no way flexible, scalable, secure, or contractually backed up by SLAs.
It has to be said again and again: Every minute that you put into a proper concept and a decent cloud architecture is likely to save days or weeks of effort in the end. So if you decide in favor of the cloud: What does that mean in detail? To make this even more tangible, and from our point of view, we at diva-e are always talking about digital projects, digital platforms. Digital platforms have to be operated in the cloud these days. There are now too many advantages, but I have to do my homework, I have to be aware of the disadvantages of the cloud, and I have to find answers to them. I have listed here on the left what should be done roughly when you start in the cloud. When you start in the cloud, running a digital platform, you should take care of all these things that are listed here on the left. And you actually start anywhere in the green.
You have to think of it this way: The cloud infrastructure, the public cloud providers, they provide the appropriate services, of course. They can be clicked together through a back office and they're operational, but I have to do it. I have to do every step myself and I have to know what I'm doing, of course. If I, now I'll take the first point: Authorization-Concept: If I'm not clear what rules I need in my application, who has access to what data, how do I want to create the password policy? Do I want to use two-factor authorization or not or partially? Then these are all issues that come back to me in the back when I'm live with the system. Because adding these concepts later is often extremely expensive. So at the beginning, already during the project phase, you have to think about it, go into it, work through these individual points with consultants, which helps to save a lot of time in the end. This is shown once again on the right-hand side. If we run a Hybris or a Spryker system in the cloud, for example on a Linux system, a Docer environment that is managed with Kubernetes. Then I'm running an area that quickly becomes very complex.
You can already see the multitude of boxes stacking up here on the right. This can be expanded very quickly, if I now consume services, cloud services, I am quickly at many, many boxes about which I say yes, which just have the task of taking care of. And I can only do that with automations. At diva-e, we always implement cloud applications in an automated way. That means there is an automation script, Terraform or Incibles are just two examples of the technology we use. There are automation scripts that do all of these things according to the-, the concepts that are on the left. And only then am I in a position to install systems at the push of a button, or to tear them down again, or to scale them, or to set up multiple systems, for example, to test things if necessary. You can't underestimate that. For us at diva-e, this is probably one of the main, yes, experiences that we have gained with the cloud, with cloud systems, over the last three years.
These automation scripts are their own software projects and they have to be treated like software projects from the very beginning. So on the one hand, these automation scripts are agile. They must continue to develop along the project path. And of course they also have to take into account that they not only serve the answers in the project, in the application, but on the other hand also serve the requirements of the cloud, because the cloud itself, the cloud providers, but also the cloud services are constantly evolving. And there, too, I have a permanent update mechanism that I have to take into account. (4 sec.) Now I'll come to the SLA dilemma. Now we have understood what we need for normal digital platforms, average digital platforms for a medium-sized company, just quickly-, in the cloud quickly 30, 40 services that play a role there. That I normally consume in a cloud environment. Example is a DNS service. Of course, I need to have my own network infrastructure that I set up, and it only works if I use a DNS service. That's relatively easy to understand. If we take the example of Microsoft Azure now, I've analyzed that a little bit. There are about 700 such services offered within Microsoft Azure. So, as I said, from the very simple DNS service to Active Directory to complex services such as artificial intelligence and machine learning, a huge range.
An enormous number of services are offered, and of course I can consume them all. Of course, I can use them all. And of course I can pay for all of them. Microsoft loves this model. It's how Microsoft earns its money, and it's where a lot of innovation takes place. Many new services are created. If you look at the SLAs that you find at Microsoft, only 91 of the 700 services are even mentioned in these SLAs. Each of the 91 in turn has also-. Let's turn it around and say again very briefly: So over 600 services have no SLA at all to begin with. So. Of the 91 services, each one kind of has different rules. There are different availability times. There are special tariffs. There are dependencies. Sometimes it's 99.9 percent within 30 minutes. Sometimes it's 99.9 percent within five minutes. It's very, very complex when you get into it. And there are, of course, to mention here for example: There are also 15 services of which it is explicitly mentioned that there is no SLA for this. That means that the aim is only to provide this service, but Microsoft does not see itself in a position to give a fixed SLA for it. Now I was thinking how do we make this tangible, that we can compare the three systems.
And I selected 30 random services out of these 91 and calculated the SLA that results if I use these 30 systems, these 30 services randomly. And then I basically come up with 98.59 percent here. That would mean-. If you take this as an SLA for the digital system, it would mean that you would have to calculate ten hours of downtime per month. Now everyone can decide for themselves whether that makes sense or not. If I have a business-critical application that is down for me, yes, within ten hours once in a month, everyone has to think about what that means for someone. The whole game again for Amazon. Amazon web service, about 750 services are listed there on the website in AWS. The SLA includes 107 services. However, I also looked extra again for Kubernetes. Kubernetes is not listed either, so it doesn't have an SRA, not even on Amazon. By the way, not on Google either. And again, I picked 30 random services and did the multiplication accordingly. Then I arrived at a value of 97.6 percent system availability, corresponding to 16.7 hours of downtime per month. The whole game again with the Google Cloud. About 700 services in the Google Cloud as well. All roughly comparable again.
On the right-hand side, you can see that these are similar. All always similar themes, very comparable themes that are offered there. The SLA is very thin. There are only 38 services, partially only, actually only 99.9 as a maximum. Kubernetes is not there either. And if you calculate all of that together as an example, you come up with only 97 percent or 20 hours of downtime. From our point of view, this is all a dilemma - a dilemma for business-relevant digital platforms. Imagine, for example, we run IOT platforms at diva-e, products have to work. If products are down for 20 hours a month, it's hard to say that as a provider of a product with an IOT component, you won't get a call from the customer or be taken into recourse altogether. As I said, these SLAs are first of all the standard SLAs that are offered on the websites in the public cloud area. In the private cloud space, I might have a few other options there, but before you go deeper there, one more thought on the dilemma of the standard product providers: There's another way of looking at it that we're seeing here right now. More and more standard product providers, such as Bloomreach, Intershop, and SAP, are offering their products in software-as-a-service mode. Yes? This means that the standard product provider offers a standard product based on a mostly public cloud provider such as AWS, Azure or Google Cloud and also provides a corresponding SLA. Of course, here again the question of demarcation is not quite cleanly clarified. Is this all completely included in the belly or not? I have there also very schwammige statements on the web pages unfortunately only found. And also the sole SLAs, which the standard providers offer by default at least, are very different. There is a premium variant at Intershop times as an example of an e-commerce system Intershop. Response time there is 30 minutes.
With SAP-Hybris standard contract is offered 24 hours response time. Huge discrepancy and of course for an e-commerce system perhaps not necessarily meaningful. You have to take a closer look: Which SLAs are available? Or rather, which SLAs also fit my business-critical application? In addition, we are of course talking about the fact that we have a customized project. No standard product is used as it is provided by the standard vendor. For the Customized-Project no standard provider takes over a SRA. In addition, in the context of such a digital project integration APIs communication takes place to EAP system third party system, CAM system. This communication is also never part of the SLA of the standard product provider. And, of course, there are still the classic service tasks in connection with operations, with cloud operations. I have now only listed service management, spending control, security management and corporate governance again here. There is no statement on this either. This means that I also have an SLA dilemma here, if I operate a business-critical digital platform in the cloud, I have a large gap between what I can buy as a license in cloud mode with SLA and what I actually need. Because let's not kid ourselves: The overall system must work and must be backed up by a corresponding SLA in order to provide or be able to provide what I actually need in business operations in order to make my customers happy. That's why we at diva-e offer various cloud services.
One is what we offer at e-cloud application management. That comes with the option to complete service levels 24 times seven in four hours restoration time. So that's not response time but restoration time. We are very proud of that. We can offer this service in this form in private cloud, which we operate ourselves at diva-e, or in public cloud Microsoft. We are currently in the process of looking in to see if we can offer this for AWS as well. The decision has not yet been made one hundred percent. There are simply a few issues that still need to be clarified. On the other hand, we offer diva-e cloud consulting. That's the whole issue: How do I implement projects so that they function appropriately in the public or private cloud environment chosen? We can support migration from monoliths. We can support dev ops systems. Cloud automation we have gained a lot of experience, we can offer. We have architects there who can advise. And last but not least, security management and corporate governance are parts that we offer as diva-e cloud consulting. Last slide so far from my side: a few customers for whom we are currently already offering this service. Unfortunately, I also have no idea why these are only blue, black and red logos. Probably there are no other colors. So I'm very interested to find more customers, especially green and yellow customers here sometime. And at this point I would like to thank you very much for your attention.
Angela Meyer: Thank you, Sascha for your very interesting input. Of course, we will no longer have an SLA dilemma here. And exactly. We are now looking forward to your questions and are now ready for the Q&A session. And there are already the first questions coming in. Sascha, I'll ask them directly to you. The first question would be:
How much does this service cost in a cloud-typical way?
Sascha Sauer: Well, yes, our service is probably meant here, the diva-e customer service. For a small solution, you have to calculate that it starts at about 2,900 euros per month. That is such a small system. Of course, it can also become significantly larger in the larger version. Yes? You also have to see it in relation to what you pay in the public cloud or with private cloud infrastructure. We are now in a position to offer very attractive prices there, of course. We have a team of about 40 engineers who are available and who provide the service.
Angela Meyer: Exactly. So we'll be happy to go into more detail on an offer afterwards. So. I would now like to take up the second question here and a participant would like to know:
Why don't the cloud providers do something like that?
Sascha Sauer: (4 sec.) What don't they do? The SLA or?
Angela Meyer: Yes. Da-, the service.
Sascha Sauer: So well, good. They have a different focus so-. If Microsoft, Amazon, of course they have a basic infrastructure that they can manage very efficiently. That's why they are, let's say, also flexible, and can also, let's say, shift resources back and forth very quickly. In any case, this is a simple business that they have to operate. But dealing with the specific application that actually generates added value for the customer is not the focus. Instead, it is really about individual functionalities such as a managed instance of a database, let's say a Microsoft SQL database, which I receive as a managed instance. That's obviously an issue that Microsoft is dealing with. What I do directly in there, which data is in there, which, whether there are sales or whether a service portal is mapped with it, which of course has interfaces and so on. None of this is Microsoft's business or focus. That's why, in principle, they can't react to it at all and, let's say, offer such SLAs. We understand that a service provider like diva-e makes the corresponding offer on the market. It's the same for standard product providers. A standard product provider also looks at its standard product deck. Anything that is individualized beyond that cannot be supported, or only to a very, very limited extent. Because he would have to support it for all customers. That's probably another installation problem in terms of service. Yes.
Angela Meyer: Yes. Okay. If this question has been answered so comprehensively, I would like to take up the next one.
And here a participant would like to know whether he can have already existing services or already existing applications managed by us, by diva-e?
Sascha Sauer: That is possible. We have done that. We have also taken over responsibility for projects that other service providers or the customer itself have implemented, which were already set up in the cloud environment, for example. What we do is that we still need a certain transition phase beforehand, because we have to get to grips with the application. If necessary, we also have to counter our operating standards and check whether we can operate this solution, but in principle, yes. We do that and we can then offer the corresponding SLAs for these solutions if they meet our operating standards.
Angela Meyer: Great. Yes, we would like to call on the participants: If you are interested, please contact Sascha and his team. They will be happy to look at your existing services and applications. So. It looks good. Schreiber: So all questions answered here, Sascha. Then please click again on the next page.
Sascha Sauer: Yes, Angela.
Angela Meyer: And then, of course, we would be delighted if you would register for further webinars, which we will organize together with our technology partners and customers. You'll find all the information you need in our diva-e newsroom. Just enter diva-e, newsroom and there you can register for our next diva-e webinars. Exactly. Yes. Then I would bid you farewell. Thank you very much, Sascha for your input and thank you for participating. We are looking forward to the next webinar and wish you now a nice sunny afternoon.
Sascha Sauer: Bye.
Angela Meyer: Bye.