As we mentioned in the intro of the series, we are looking at the gap between on-premise and cloud systems from different angles. The first article in the series was "Cloud: Why?", which we talked about why an organisation would decide to go cloud. In this article we will discuss how that decision changes the solution architecture and what are the right approaches to follow.
Why?
The first question here is, why would going on cloud change our architecture? Aren't there any VMs over there? Can't we just build our existing architecture on the cloud?
Yes, you can. And yes, there are VMs over there. But why would you? Why would you want to build an on-premise look-alike system on the cloud? If that's what you want, why move at all? Apart from cutting down some hardware maintenance costs, there is absolutely nothing else you'll be gaining from that.
If you are moving towards the cloud, you need adopt the design patterns and best practices over there. They are called "best practices" for a reason: They can provide light on your treacherous path, reducing the time and effort needed for your transformation.
What?
Let's take a look at what needs to be changed.
There are some things on cloud that still works the same way. Let's assume that you have a web application that connects to an API, which talks to a SQL database and returns the records. This still works the same, the components you use just change names:
| On-Premise | Cloud |
|---|---|
| IIS Application Pool | App Service Plan |
| IIS Website | App Service |
| SQL Server | Azure SQL Server |
| SQL Database | Azure SQL Database |
In the on-premise world, you host your Web and API in two separate IIS Websites. API then connects to your SQL Database under a SQL Server, which probably is generic and has many databases on it. On the cloud, you deploy your Web and API on App Services, which are equivalent to IIS Websites. You also have an Azure SQL Server that has your Azure SQL Database.
Then what changes in this example? Well, many things but one of them is the authentication. On-premise world (the ones running on Windows platform) has Active Directory Domain to take care of it. You just enable Windows Authentication and bam! No anonymous user can connect to your site. If you want to do authorisation, you can check if the user is in the correct AD group. If you want to connect to your API, you ask for service accounts and then enter those credentials to Application Pools as Application Pool Identities. This way, your application can connect to other apps that has their Windows Authentication enabled.
But when you move to PaaS on Azure, there is no domain available there. You cannot enable Windows Authentication; your website is living on a machine that is not on your domain (and probably running many other apps from other people at the same time).
Things like this, even they're small (especially when they're small), can cause dramatic changes on your application architecture.
How?
Use PaaS and SaaS
There are many tools that cloud providers give you as PaaS (Platform as a Service) and SaaS (Software as a Service). These tools allow you to focus on your application development and forget about the maintenance of these services in the background. All you have to know is what are the SLAs and follow up some planned maintenance times. The picture below is #2 in my favourites (#1 is the Liskov Substitution Principle motivational picture with the duck example) and shows clearly the difference between on-premise, IaaS, PaaS and SaaS.
PaaS tools provide you the proper runtime and a deployment strategy, which allows you to develop your applications and directly launch them on the platform. This makes a huge difference on delivery speed. It also changes most of the patterns you know from the on-premise world. Things work different on cloud; authentication and authorisation is different, logging is different, reliable messaging still looks the same but feels different.
These differences will change your application architecture, mostly in a good way. Let's put changes on a concrete perspective.
Let's visit our example again. You found out that there is no domain available on PaaS services. After some heavy drinking and whining, you realise that there is something called OAuth and Azure Active Directory implements it. You create an Azure AD, enable OAuth and OpenID Connect on your applications, create service principals and bam! You have a lift off. (We'll discuss these security stuff in detail in its own article)
Azure Specific Tools
There are many things Azure (and other cloud providers) provide. Trust me, the list is endless. When I visit Azure portal, sometimes I feel like a kid breaking free from his parents and races towards the snacks aisle in a supermarket. For most of your use cases, there is a tool available there.
(I suggest you take a look at Azure Info Hub, it shows almost everything Azure is capable of. It also includes documentation, videos, examples, links, etc.)
You also get lots of new toys to play around (cheeky childish smile on). If you want to do some IoT based project, Azure gives you Azure Stream Analytics and Azure IoT Hub. These tools can process huge amount of incoming data on the fly and produce the value your business needs from those devices.
You have very large files that you batch process through the night? Well, there is Azure Data Lake Analytics, it's the perfect tool for the job.
Do you have analysts that slice and dice the data already? There's Azure Databricks to help them do that with the help of Spark, Scala, Python and R.
Do they want to use some machine learning to gain analytics and insights? Azure Machine Learning has an extensive library/market already and Azure Databricks plays well with it.
You want to run some code triggered by a service bus message but don't want to go full scale with App Services? You have Azure Functions and Logic Apps. They are both part of the Server-less Architecture that Azure provides.
You prefer containers? Azure has Azure Kubernetes Services. It's managed and quite powerful, you can easily deploy your container and have a beer on the balcony right away.
You need a No-SQL database? There's CosmosDB. It even has Graph DB support with Gremlin, in case you need it (I do at the moment).
Conclusion
I mostly mentioned Azure here but there are equivalents/alternatives on other cloud providers such as Amazon. They are equally powerful.
Bottom line is, you don't have to develop something on your own or install the same product and use it. There are many things available out there; you just have to choose them and integrate them with your applications. These will drive changes on your traditional solution architecture but remember: Change is good.
Don't forget to check out other articles in the series; each of them will take the matter from a different angle. Next one is going to be on Application Development and CI/CD.