I am using Azure Table storage to store the data of my application. I need to build an API to retrieve the data from Azure table storage. There are like a million records in the table. In the initial stage, my API would be getting approximately 100-1000 hits per day. What would be the best choice to develop that API on, API apps or Service Fabric?
It depends on a lot of aspects:
How do you want to maintain it?
What performance requirements do you have? Do all those 100-1000 hits per day happen at the same time or are they distributed across the day?
How do you want to handle scaling?
As described by #feranto the main difference is the architectural pattern. The decision will have a lot of implications for you, not only when it comes to development, but you will have to consider how to maintain your application.
Only based on your short description, it sounds like a relatively straightforward solution and not very complex nor very high performance/scale requirements. Given that, it might be easier for you to go for a more basic API App. Service Fabric is an excellent framework and architecture that allows us to build very flexible, highly scalable solutions, but it should be noted that that also comes with a lot more complexity when it comes to handling, monitoring and maintaining both the underlying service cluster and it's applications.
Setting up an API App, connecting to an Azure Storage table and control that with for instance Application Insights is relatively straight forward and you can find a lot of documentation and samples for that. As a contrast, Service Fabric is fairly nascent in documentation and samples, and you would have to read up on a lot to get a basic stable solution running if you are new to it.
The main difference between Azure API and Azure Service Fabric is the architecture pattern each one follows:
Azure API APPs supports a monolithic architecture. You have all your code running as one single package. You can develop this using Java, PHP, nodejs, python or .net.
Service Fabric follows a microservice architecture. Every service is deployed on a separate node, which can scale independently, and you can monitor the health of every service in every node. You can develop this using Java or C# mainly.
Here you can see advantages and disadvantages between microservices and a monolithic architecture.
Related
Please help me understand why we say azure functions is a serverless compute service. It does require cloud to host it and run. Cloud is also a server still why we are saying it is serverless?
Serverless computing does not mean that servers are out of the picture. Servers are very much required, just like they have been for all these years, or else, where will your code run. The reason why the phrase was coined is that as a developer, you do not need to worry about what server your code runs on. In fact, you do not know which server it eventually runs on. Once your code is deployed, Azure assigns the responsibility of executing the code to the next available server. What Azure ensures, and what is ultimately important for you, is that your code will execute whenever required.
Ref: Serverless Computing with Azure Functions
Hope it makes sense :)
To get a better idea this is how we evolved. Cloud providers are making sure we should only worry about the business logic but nothing else.
IaaS (Infrastructure as a service)
You get a running VM somewhere in the data centre but you are required to maintain everything. From Deployment to patching your VMs or anything running on the VM.
PaaS(Platform as a service)
You are not longer required to maintain platForm but you are still responsible to manage your server in terms of load balancing etc.
FaaS(Function as a service)
Servers are abstracted from you . You are only required to maintain your code without worrying about what's under the hood or how to load balance your servers. It's then cloud provider responsibility to package your code and run it for you. But servers are still there.
Going by the official documentation of Azure Serverless computing service, Azure Functions can be defined as;
Azure Functions is a serverless compute service that enables you to run code on-demand without having to explicitly provision or manage infrastructure. Use Azure Functions to run a script or piece of code in response to a variety of events.
Azure Functions is an event driven, compute-on-demand experience that
extends the existing Azure application platform with capabilities to
implement code triggered by events occurring in virtually any Azure or
3rd party service as well as on-premises systems. Azure Functions
allows developers to take action by connecting to data sources or
messaging solutions, thus making it easy to process and react to
events. Azure Functions scale based on demand and you pay only for the
resources you consume.
Here the serverless compute service is like a metaphor which implies, the end user doesn't need to manage the servers or infrastructure to run the applications over the Azure and can spend time to focus on managing and improving the business logic.
Few more points to consider,
Serverless in Azure builds on an open-source foundation, the core of
which is Azure Functions, an event-driven compute experience and open
source project. Community contributions include support for new
languages, integrations and deployment targets.
Azure Functions can be used on-premises, in hybrid environments such as Azure Stack, on IoT Edge devices and deployed on top of orchestrators such as Kubernetes – as well as in other clouds.
They enable faster time to market with lower infrastructure and operating costs.
There are heaps of definition of serverless which you can easily google. But I will share my understanding anyways.
1. It does require cloud to host it and run.
You are correct with this. But anything on Cloud requires Cloud, doesn't it? Azure being one of the cloud providers consists of hundreds of services to cater to different needs people are after from using Cloud.
2. Cloud is also a server still why we are saying is serverless
This is not quite right. Cloud is different from a server. Server is a physical box sitting somewhere. With hundreds of thousands of servers all over the world, Cloud hosts all sorts of different services on these servers.
The reason we say Functions are serverless is that the infrastructure of hosting a Function is abstracted away from devs. It is still deployed to some servers but Azure is responsible for all the resource managing, configuration, load balancing, scaling and networking etc. It allows developers to focus primarily on their code, not having to worry about servers.
I need to deploy two node services to CF (each service in its own container).
The apps need to communicate. How is it recommended to implement this communication? I can't find any guide which explains service-to-service communication in CF, and since it should deploy to the cloud I need some best practices. Some examples will be very helpful.
This is a classic question that always come to solve any enterprise application integration pattern and it comes down to the point that, what type of integration needs one has.
If an app want to have synchronous communication to get a real time response, RESTFul APIs are the most loved integration style of this age. But one also need to consider that, creation of huge numbers of APIs (which is the downside of going with Microservices based architecture) also brings-in the huge overhead of maintaining the set and locating the correct one. An API Gateway and a Service Discovery tools should be of help here. I am a novice about Blue-mix but you can surely host a Spring-Cloud-Eureka or Consul based Service Discovery on it to serve the purpose, and similarly Spring Cloud Zuul to have an API Gateway.
Another simple catch here is to ensure not to build one central service as fat spof to cater to whole of your microservices world but rather have many such services each catering to a contextually bound microservices.
On the similar line, if the need is to have async communication, message brokers such as - RabbitMQ, Kakfa should be the best and simplest integration style for apps to communicate. The same catch of not building a SPOF service but rather have separate service instances one each for a set of bounded microservices applies here as well, with all these instances being further federated for wider communication should be taken care of.
Your answer will depend on what kind of communication you want between your apps.
If you're looking to deploy a microservice-based architecture pattern for your Node services, i.e. server code that performs an independent, granular business function, I would recommend getting started reading the docs here and using the new Bluemix Developer Console.
Here there is a growing set of patterns and starters that you can use to understand and develop cloud native apps that can communicate to each other by exposing API endpoints compliant with the Open API specification and auto-generating SDKs for your omnichannel client applications.
After downloading the selected starter, you can modify the code to expose an API that performs the business logic that you need. Subsequently, you can run your project locally in a container or deploy it to Bluemix using the bx dev command line tool.
After setting that up, you will have cross platform, language independent communication between your microservices and client applications.
I want to host an Orleans project on Azure, but don't want to use the (classic) Cloud Services model (I want an ARM template project). The web app sample uses the old web / worker model - what is best option? There is a Service Fabric sample - is that the best route? The nearest equivalent to the web/worker model is VM Scale Sets - is that a well tested option?
IMO, app service is closet to web role.
Worker role however, depending on the point of view
From system architecture point of view, I think Scale Set is the closet. You get an identical set of VMs running your application. However you lost all management features. How your cluster handle application configurations, work loads on each node, service interruptions from server failure or deployments are pretty much DIY. Also you need to provision the VM with dependencies for your application.
From operations point of view, I think Service Fabric is the closest. It handles problems above but then you are dealing with design/implementation changes and learning curve from the added fabric layer in the architecture. Could be small, could be big depending on the complexity of your project. Besides, service fabric is still relatively new and nothing is for sure. Best case you follow the sample change a few lines of code and it works like a charm. Worst case you may want to complete refactor orleans solution into service fabric solution.
App service would be the easiest among the three. If it doesn't meet your requirement, I personally would try Service Fabric. Same reason why people are moving to cloud and you would opt for ARM solution.
Background
Having run through the Getting started with API Apps and ASP.NET in Azure App Service tutorial (https://azure.microsoft.com/en-gb/documentation/articles/app-service-api-dotnet-get-started/), we had an architecture question arise today around the design decisions made to split out the To Do List Application API layers into a Middle tier API app and Data tier API app.
When approaching build of an application using a distributed architecture, what considerations should take place to understand when this type of separation should occur in your API layers?
Another way of asking this question is what are the pros and cons of having a separate middle tier API layer and data tier API app when building your application?
Other Questions
I had a read of Web apps architecture: 1 or n API question (see link that follows) which while being insightful, was slightly different to the question we are asking. We are talking a single domain which has separate API layers for middle tier (logic) and the data tier.
Web apps architecture: 1 or n API
This of course, depends. Deciding whether to build out what I call "infrastructure services" is very strongly dependent on your needs and your application(s).
Infrastructure tier services generally get much more re-use than business logic tier services. They are very easy to recompose into new applications. The most common instance of this is building an admin interface as a separate application.
If you have already build several applications in your organization, and have found reuse to be occurring regularly, then I would seriously contemplate infrastructure services. If your organization is writing it's first application, and you don't see this fanning out to additional interfaces, then maybe just isolate your data access in a DAO pattern, it's fairly straightforward to refactor it out to a stand-alone service later.
I think the example design is somewhat confusing. In real world, I have not seen such design yet because design looks like having every function to be http/rpc call?
My experience would be the SPA uses a Public API (or Gateway API) which then calls your Internal API / Microservices to aggregate results. It is your Microservices that may have DAOs and, most importantly, the business logic
I am designing the architecture for an Azure application, and I have a few questions on how to proceed. I am familiar with the basics of Azure, but have never built and deployed an Azure application before. I have extensive experience with conventional non-cloud, web-hosted applications, though.
My application will be the usual database-centric business system with a web user interface. We want to start very small and grow it slowly as we gain user base. I am planning to use an SQL Azure database for relational storage as well as blob storage for documents and the like. These will be accessed by a Data Access Layer, which in turn will be operated by a Business Layer. The web user interface will be built using ASP.NET and will rest on the Business Layer.
All this is very traditional, but I wonder how well it fits with Azure. I have some specific and inter-related questions:
I see the Data Layer and Business Layer as part of an Application Tier that can be deployed on a worker role, whereas the web user interface can be deployed as a Front-End Tier on a web role. Is separating the business and presentation logic like this a wise decision on Azure?
Having said the above, having two separate roles wouldn't make sense while the user base is very small, so I would rather deploy everything together on a single web role until we get bigger. What do I need to do to make sure that these two tiers can be easily reconfigured to work as either one or two roles with any recoding?
The communication between the web user interface and the Business Layer must be fast; I am concerned that it won't be very fast especially when these two are deployed as separate tiers on different web/worker roles. What is the best communications mechanism in Azure that I should use? I have considered queue storage, service bus and virtual network, but I am not sure how to make a decision here.
I have been reading some best practices posts and documents online, but they seem to address advanced issues. I would rather like to have answers to these quite basic concerns in the form of pointers to best practices articles or the like. Thank you.