The 3 Most Important Reasons Why The Cloud Will Win

For years, I wasn’t in love with the idea to move stuff into „some place“ that a company doesn’t own. This changed lately, as again and again I saw the infrastructure and operational costs, and what a pain they’ve become for a lot of companies — they either ignore it until they recognize the enormous amounts of money that goes into it every single month, or they cut it down until it’s impossible for any sane person to provide a stable service for the company’s business.

So I started thinking about how to leverage the potential of the cloud, what benefits there are, and if the processes and architecture which I propose to my clients actually fit into the cloud.

The outcome struck me hard. I had the feeling that for years I’ve simply been doing things wrong. After settling my thoughts for some weeks, I felt heavily inspired by the ideas in my mind, and the potential of the cloud for virtually every company out there.

So, before starting my list, I would like to explain what I mean with „going into the cloud“. Or better, what I do not mean. I don’t mean to host your on-premise applications in another datacenter. For instance, you can buy hosting for Oracle’s ERP system called eBusiness Suite „in the cloud“, directly from Oracle. What it does is, you move a huge monolith to another datacenter. Even though it’s called „in the cloud“, it is not what I mean. I mean changing your applications step by step so that they can run in the cloud and leverage the benefits of it, e.g. using serverless applications wherever possible and avoid anything that is a monolith. And your existing terrabyte, or even hundreds of pentabytes of data move with the Snowmobile (look at it, looks like a joke at first but this is serious, up to 100PB of data, and while the Snowmobile drives to the datacenter, this thing migrates and transforms your data to have it ready when you arrive).

If you decide to move your IT applications to the cloud, here’s your benefits, and they are so huge that there is actually now way around:

1. The infrastructure costs are magnitudes lower

I’ve been working with several international companies which operate large data centers for their IT. I know the costs of operating them, of scaling with business and development demands, and keeping them alive and kicking. I can tell you, that once you have moved to the cloud with fully leveraging the cloud architecture, your costs will go down by at least the factor of ten, and I’ve seen cases where it was a factor of 100, even up to 1000 — I’ve seen one case where the costs for a badly behaving system went from $10.000 per month to $40 — I’m serious! And the system was fast and more stable than before. That’s impossible, you say? You never before have looked at the pricing sheets of the cloud providers. Let me give you an example: you run an online shopping system, and you suppliers send you their current price lists and stock information every day in a simple Excel file. You have 400 suppliers, each sending one per day, with hundreds or thousands of items in it, usually in the morning within the same hour, and that’s where you have your peak load. You could do the transformation of these files into your database with AWS Lambda, and now comes the fun part: the first million requests per month are free, and after that, 1 million of request cost you $0,20 per month. To make it clear: it’s not $0,20 per request for the next million, it $0,20 per 1 million requests. This includes scaling in every thinkable way, and simply not a single thought about if the infrastructure for this is up and running.

So, the main reasons why your costs go down are:

• You no longer deal with hardware — you buy the resources you need, and when you need it, and failing hardware is not only not your problem anymore, you usually wouldn’t even notice it
• You don’t scale your hardware to the peak load, actually you don’t care about the peak anymore — if you system’s architecture allows scaling, it can handle every load, but you still just pay for the actual load, not for the whole infrastructure for the theoretical peak load
• All IT departments need several environments for testing, development, etc. In the cloud, these environments are not only extremely simply to create on demand, you again only pay for the actual load on these environments; creating another environment is not a cost factor anymore, and if your infrastructure guys are wise enough, it’s not even a time consuming task but a click of a button, and you have an environment that is completely the same as your production environment

2. Business will love IT

Sounds strange, ha?

Let me tell you a story of one of my clients’ infrastructure&operations department, and the relation to the business department.

When I came there, I noticed that the infrastructure guys were talking quite badly about new campaigns or offers to their customers from their business department. They were not actively hindering these campaigns from success, but it was very close to sabotage. To say the least, they were not really pushing things as they could have been pushing.

The reason behind that was that with every campaign, a lot of new customers used their services. Which sounds great was actually a nightmare for the infrastructure and operations guys. Every time the load increased, their systems had heavy problems because they were already running at almost their peak. Every failure in these situations costed endless effort, business was complaining as customers were calling support in masses, and they saw their investments in the marketing campaign, and the revenue sail down the river. After weeks of struggling, new hardware was put on top, and if they were lucky, they were up and running when the next campaign started. It’s clear why business and IT weren’t best friends, right? Business was not willing to invest upfront and give IT the money, and the infrastructure couldn’t deal with the additional load.

But guess what, business was totally fine to count in a small amount for infrastructure costs for each new customer they generate with their campaign. As soon as the relevant systems where running in the cloud, with a proper cloud architecture, it was scaling easily with the new load, and the extra costs for this new load where already part of the campaign budget and return of investment calculations! There was no delay between the extra load and bringing hardware in, it just scales in the cloud, with no budget spent months before the campaign to get the hardware in and setup properly.

Business urgently needs a new report, which takes ages to calculate? „Sorry, we don’t have hardware for you, pls order one.“ You will never again hear that. You have endless resources, and you can calculate to the fraction of a dollar how much it will cost business already at the beginning of the project or demand. This is what business will love about IT, that they know how much it will cost, and the confidence that it will work without months of setup and preparation.

3. Security, Data Protection and Stability are solved

All good cloud providers support end to end encryption, up from the entry point of the data down to the storage level. Of course there is data stored in a remote location, but it’s data and no longer information. Stealing it means to steel a nice collection of zeros and ones, but nobody can see your information inside the data. I’m 100% confident that this is not the case for your current, on-premise setup. On top of that, the datacenters and processes fulfill literally every regulation and law you can think of. No audits on your side which go down to every detail of your datacenter, entrance management, and handling of broken hardware. This is all certified and done by the cloud providers. You focus on giving business what they need, and how to implement the regulations into your software — but no longer for the hardware part.

Leveraging cloud architecture also means to implicitly build stable systems. How come, you may ask. A proper cloud architecture means that all components are heavily independent from each other, and heavily encapsulate their domain. They actually hide it in such a massive way, that from the outside you couldn’t tell which technology is in use. Sounds like microservices? You are right. But it goes a little bit further. Microservices, in their common understanding, are dedicated services. They scale easily, and are black boxes with well-defined interfaces. But they usually run on dedicated hardware, and scaling involves setting up another dedicated machine and run their another instance. Using serverless applications for your microservices, you get rid of the binding of a microservice instance with a dedicated (virtual or real) machine — and it makes your service scale to 1000 more instances within a second. Can you do that with your current infrastructure? Maybe you don’t need scaling in these magnitudes, but usually being able to scale means that there is something idling around until it is needed, and while it’s idling, it costs a lot of money without revenue because you can’t do anything else on it. If you are lucky, you have some more or less dynamic instantiation technology so that you can react or plan on heavy load and create instances on demand or beforehand. Nevertheless, it will take several seconds, and your plan crashes if more services than you’ve planned need resources at the same time.

There are very rare cases where moving into the cloud is not an option, for instance when realtime, or close-to-realtime signaling needs to be performed. But even in these cases, you can put the rest of your systems to the cloud and keep a small portion on premise.

During the next weeks, I will dive deeper into the background for the reasoning above, and into details regarding typical IT topics like development processes, operations, DevOps and agile development, and how these change with moving into the cloud. Follow me to stay informed.