Is Azure app service environment a good fit for microservices architecture

Question

I am looking at deploying a collection of REST services into azure. These services are to support a mobile app front end and a web based front end. I want them to be independently deployable and scalable. They will need to communicate with each other and some other Web services, APIs etc developed/maintained by other teams or third parties. Not sure if they are pure microservices but the idea is that each one is responsible for a "domain", however it might need to get information from one of the other services. For instance, one is responsible for getting/updating a customer's address and another would be for preferences.

I am not sure if I should create a separate app service environment for each service or one app service environment for all of them? Putting aside cost, is there any technical reason to keep them all in the same app service environment? My first thought was to create an app service environment for each service because this would give the most isolation but a lot of the examples online make it seem like people are deploying multiple apps/services in the same app service environment.

Thanks

Immortal

In all architecture references you'll find AKS or Service Fabric. I would go with one of them. – Trowel

That's true, however you don't want to maintain an AKS cluster (even a managed one) for a microservice consisting of only two components. – Ignacia

This is a very good question. I've always been frustrated with world been obcessed with Docker containers and orchestrators for everything. IMHO you need to run microservices only when you need granular control over computational resources allocation and sheduling (you're developing something non-trivial) or when hosting your services in a cloud is not an option. Otherwise Azure App Service is way much easier to work with, and provides most things you need. (but would be happy to hear other opininons) – Gracegraceful

Answer 1

Microservices is one of these words that everyone has its own definition in his/her head but I understand that you want to group functionality in a domain level so you avoid a humongous constellation of services requiring maintenance in the long run. I would try to simplify things as much as possible.

1) App Service Plan -> managed virtual machine

Imagine an App Service Plan like a managed virtual machine with everything put in place for you. You can scale up (give more resources) or scale out(create multiple instances with a load-balancer automatically set up for you). The minimum production level plan P1V2 comes with 3.5GB of RAM and 210 acus. It is very strong for an average microservice that would serve some calls and persist data in a db.

2) Grouping microservices in one plan

I would suggest you do. You may state that the cost does not matter, but it will actually matter when your company grows and you will have 100 services running each one on each own plan. Also consider the unnecessary spend of resources if you deploy one by one (you could probably use dev/test plans to deploy your apps in order to get fewer resources but that comes with limited functionalities as well).

So how to group? There are many way to do it, I would only name some of them I have seen working out well.

1. By domain. If you have two or more service that are strongly related to each other, you may need them in the same plan so if you want to scale out and boost performance you will scale out only one plan.

2. By external depedencies. If some of your services are being called by third parties or give call to third parties then it might be a good way to group them together in one plan and place them behind an api gateway so they keep their public ip static, no matter if you want to delete a service and recreate it. Some third parties also whitelist IPs so it might be a good idea to keep your outbound ip address static.

3. Performance. Since the services are going to share resources it is important some very essential services to be isolated. Same thing applies to services that may have big picks of workload over small period of time that might drain the machines resources delaying all other services hosted together.

Answering suggestions in one of the comments, Service Fabric is not the future of microservices in azure. It is maintained but it is not going to evolve any more than that. Microsoft is shifting their customers towards AKS or Web apps. But in my taste AKS is a bit difficult to maintain, even the managed version.

Concluding, I think that app services and web/api apps are quite good of a choice for deploying microservices in azure. Keep them in the same region and split them poroperly. It is quite easy to set up and maintain.

I hope it helps you. Feel free to reach me if you want more specific info.

Senhauser

Yes, I was thinking along those lines of having a sort of "meta" group. Where a couple of services that are more related can be grouped into 1 ASE. I have looked at AKS and it seemed to me it required a lot more work to build/maintain which ASE gives you for "free" (free as in no effort). The only downside I see so far is that I am hearing ASE takes a lot longer to scale up. I have to use isolated ASE. – Immortal