The naive architecture
My first instinct is that we need a frontend, an API and a database, but for this project I knew from the start that this wouldn’t be enough. A key component to the application is that Windows desktop application, that we need to scale. Containers came to mind early, and with that, the dreaded Kubernetes.
One thing we were absolutely sure of, is that this application needs to scale well. That was one of the requirements from the client, and my understanding of the clients needs confirms this. Scaling and cost are key concerns, tho the cost will be less of a concern once we hit the market.
Cloud it is, and since all the cloud providers can serve our needs, we decided to go with Microsoft Azure, because the team have decent experience using it. What we might lose in cloud cost, we will make up for in cost for developers struggling with a cloud provider they don’t know.
Early discussions made it clear that Kubernetes will probably only give us headache, without any benefits. We don’t really need the kind of orchestration that Kubernetes provides, we actually only need to start a separate instance of our container per execution, making the architecture a great deal easier to comprehend.
This leaves us with a naive architecture with a static web app to host our Angular frontend, an API App for the API, a Container App for the Windows Desktop App and some kind of SQL database in Azure.
That Windows Desktop App is a major concern, but the developer is (at least so far) easy to work with, and have already provided us with the option to run the application headless. We’re looking into the possibility to split the application in three, since it does three things that actually has different scaling needs. Also, we would like it if the app could run on a Linux container. The application is written in modern .NET Core, but have some dependencies that might be problematic to run on Linux. We’ll see, developers are more expensive than Windows containers.
For login, we decided to use services from Microsoft and Google. The service will be sold to agencies, and we figure that most business use either Microsoft or Google applications already. This will lift the burden of handling logins and passwords, and most likely also provide a better login experience for the end user.
This is an architecture I’m convinced will break, but I’m not sure how and why. That’s what makes it naive, right!?
