Back in the days (ok, so about 10 years ago), virtualisation was the closest thing most organizations came to what we would refer to as cloud computing today. This often meant a virtual machine on a on-premise server, possibly with some connected services such as automatic backup of disks and managed upgrades. For most organizations, renting parts of a server machine was way cheaper than buying their own hardware, but besides from that, virtualisation didn't offer much more. You still had to install your OS and manage packages, install all your software such as web servers, databases etc., and deal with security from top to bottom.
When the cloud providers came along (or became popular, I should say) they introduced a whole new concept of virtualisation, by offering virtual CPUs, memory and disk space, not limited to a virtual machine. Amazon was the first provider to offer what we today would refer to as managed services, with their S3 and Ec2 services on the AWS cloud platform. The simplicity of outsourcing management of services used by applications made cloud platforms more and more popular, as the number of services offered increased. Today, AWS has hundreds of products to pick from, and other cloud platforms such as Microsoft's Azure and Google Cloud Platform, are not far behind.
Of course, letting someone else do the work of managing your IT platform is gonna cost you. Many organizations have mistakenly calculated that the money saved on not having specialized infrastructure staff managing all the on-premise hardware, would pay for the cloud spendings, until realizing that running applications in the cloud is a complex task. Many companies, unfortunately, learned cost management on cloud platforms the hard way, after their cloud journey was completed.
Does this mean that cloud computing is simply more expensive, and that moving to the cloud platforms has increased IT costs for companies? I will share some of my experiences from working with cloud technologies and how to impact spendings.
The cloud mindset
When starting out on the cloud journey, there is one fundamental rule (there are more, but this is an important one) that unfortunately many organizations are not aware of / don't care about:
You build cloud applications, you don't run applications in the cloud!
In order to utilize the performance of a cloud platform, and even cut costs while doing it, it is important to switch to a cloud computing mindset. A cloud platform allows for (or requires) a cloud application architecture. This means that you want to design your application architecture so that your applications are built around the cloud services that build up your application, instead of, as in a more traditionally manner, integrate the services. Let's have a look at some drawings to illustrate this.
The (extremely simplified) architectural drawing above illustrates an application running in Kubernetes on an on-prem server. It fetches email attachment files stored on the disk and email addresses stored in a PostgreSQL database, and utilizes a cron-job to schedule sending out emails to recipients.
Now let's have a look at how this architecture would look in an AWS cloud environment.
The illustration above shows how the application from previous, on-prem architecture illustration, could be set up on AWS. Here we use S3 for storing our email attachment files, the RDS database service for storing email addresses and instead of running an application in Kubernetes, scaling up during peak times, we use a serverless architecture by utilizing a Lambda service in AWS, which will give us the power we need, when we need it. The SNS messaging service in AWS is responsible for sending the actual emails to recipients.
What's interesting to note about this (again, extremely simplified) example, is how different the architecture looks on AWS from our on-prem server example. Now, we could very well have migrated the on-prem example straight to AWS, as it is, using EKS for running our app in Kubernetes, and run cron-jobs and a database on an Ec2 instance, but of course, we need most of the features provided by the managed services provided in a cloud platform, such as automatic database snapshots, backup and access to our stored files, logging etc. By switching to a cloud mindset when we design our application architecture, we can make use of the cloud services, at lower costs than running the same system on an on-prem server.
For this particular example, the Lambda function would only trigger when we run the batch jobs, i.e. sending emails, and we pay per second it runs. The RDS service in AWS is billed by instance hours, backups and storage. By temporarily stopping our RDS when it's idle, that is, between batch jobs, we save instance hours, which can be, especially for large DB instances, substantial. S3 offers multiple price ranges, depending on what type of access you need to your data, making it an extremely versatile and cheap choice for storing large amounts of data.
About managed services
When working with clients I often experience discussions around if an organization should "lock into" a particular cloud provider, or to try and aim for an architecture that would allow the organization to switch to a different cloud provider at a later stage, or go back to on-prem hosting. My experience is that this kind of "multi platform" architecture should be avoided unless there are real strong arguments for it. For example, instead of using the DocumentDB service in AWS, which provides a flat, object database engine, mimicking MongoDB with most of its functionality, an organization could integrate MongoDB's own managed service Atlas. At first glance, this could seem tempting, because the Atlas service is slightly cheaper (by the hour) and it is platform independent. However, by moving you database out of the AWS platform, you will have to deal with security and access management outside of your AWS infrastructure, which will have both technical and functional implications, that needs to be considered. The larger your cloud computing based system gets, the more problematic and annoying external integrations can be, both functionally and technically.
The managed services on a cloud platform, packs features that your applications most likely need. Logging, backup, security, accessibility and interoperability are stuff that needs to exist in all system architectures. I have been on multiple projects where I have seen the effects of "opting out" of many of the managed services provided by cloud platforms, and it has always resulted in the need for complex technical solutions, with issues affecting deployment processes, security and cost.
To get the benefits of modern cloud computing, you build cloud computing systems, you don't run systems on cloud infrastructure.
Conclusion
This article has been around the importance of understanding cloud computing architecture, in order to run cost effective applications in the cloud. While we have not discussed much details (we will save this for coming articles), we have looked at one example of architectural difference between a cloud computing app and an app running on an on-prem server. Designing architectures for cloud computing requires experience and skills, but above all it requires the ability to understand the organization's requirements on both a functional and technical level, and how to best meet these requirements in a efficient and cost effective manner.
