I am having a hard time understanding Windows Azure service bus and access control concepts. In layman's terms, what are they? What are they used for?
The Service Bus component of Windows Azure is meant to handle the problems arising from services that are living in multiple networks. Basically, a service bus just makes it appear as if your code is running on a single machine, while in reality it could be running anywhere within the Azure datacenters.
Access Control lets you use "federated authentication for your service based on a claim-based RESTful model. (Sorry, copy&Paste from an O'Reilly book about Azure!)
Basically, when you create an Azure site, application or service, it could be running on any of the thousands of systems within the datacenter. And each of those systems has it's own IP address, it's own network, memory, processor and whatever more. To let them collaborate and to appear as a single system, these two services have been created.
If you want to learn more about Azure, this would be a good moment to buy a book! :-)
Azure is quite complex and service buses and access control are a bit more advanced topics.
Service Bus is a solution for the integration between multiple applications whether they are hosted on the same infrastructure or even spread along multiple infrastructure or/and Cloud Computing provider. If you search more in the internet you might find a lot about EAI (Enterprise application integration) here is my blog post about this topic:
http://hhaggan.wordpress.com/2013/03/07/introduction-to-enterprise-application-integration-eai/
and here another that I hope that helps you understand better what is the service bus:
http://hhaggan.wordpress.com/2013/03/09/introducing-service-bus/
in another words, it is a messaging platform that helps you communicate with multiple applications, softwares or services no matter what programming language they are written with or on which os or platform they are hosted on. you will feel its effect specially when you work on connecting multiple nodes together, I don't mean 5 or 6 nodes but 10 and above.
Certainly there are several types of service bus, whether they are based on relayed messaging service or brokered messaging service, each one of them has several uses, its purpose and way of working.
For the Access control, this is so easy, it is a way of authentication and authorization for your application using third parties, It is a claim based identity that you can do the required authentication through the third party database. you wont need to build everything from scratch in your database. this helps a lot during development and I believe that this can help a lot in social media marketing and branding because of the use of facebook, twitter during the authentication.
Related
We produce an enterprise DLT (Blockchain) application for big banks, FMIs, exchanges etc..
Being distributed each instance of the application is installed on-prem for each customer, as they must remain the sovereign owner of their private keys.
We want to integrate with a SaaS application that is widely used in the banking sector. We intend to achieve this by writing a "connector" which will also run on-prem and be able to communicate and marshal data between the SaaS system and our on-prem system.
Events occur in the SaaS app, which must then trigger something to happen in our on-prem app.
The SaaS app has a RESTful API as well as webhooks. So there are 2 options in my eyes:
Poll the RESTful API
Con: This is inefficient as most traffic will simply be "any new events?" "no"
Con: There will be some latency between the event occurring on the SaaS system and our on-prem app being triggered
Pro: This is stable. If the connector (the thing doing the polling) goes down, it will pick up any missed "events" from the SaaS system when it comes back up and process them
Pro: There is no requirement to allow internet traffic into the firewall - the comms are all outbound.
Use the webhooks
Pro: Very efficient
Pro: Get events in near real-time
Con: What happens if the connector is down and we miss a webhook? Does the SaaS system need a retry mechanism? We need to ensure that we only process messages exactly once. (this is important because the action we perform moves large amounts of funds so double processing would be extremely bad!)
Con: The bank would need to punch a hole in the firewall to allow the SaaS app to communicate into the connector - the bank's security teams won't like this IMO.
Is there a common, enterprise ready, security policy friendly way to do deal with this?
I think here you can use RESTful API with an enterprise ready-solution for API management. I would recommend that you explore APIGEE and see if it fits your usecase.
APIGEE is a platform for developing and managing API proxies.
An API proxy is an interface to developers that want to use backend services. Rather than having them consume those services directly, they access an Edge API proxy that you create. You can have it on cloud and also on-premises.
Here, you will solve your two main issues which are events management and latency.
I have 40+ micro-services using Windows Service Bus 1.1 with lots of Queues/Topics/Subscriptions and messages, and I am going to use Azure Service Bus instead.
How can I move all the information and the farm on-premises to Azure?
Not sure you can "move" anything off on-premises into Azure. What you will need to do is to transition your solution. And that's where it's getting a bit hairy.
First, answer the question if you can stop your system for a massive redeployment w/o impacting the business. If you are (which would be rare), you're in a luck as you could take the system offline and "transition" to the new topology on the Azure Service Bus. But that is highly unpropable situation.
A more realistic scenario is when you cannot turn down the sytem. An approach to take is to transition gradually. 40 microservices you've mentioned operate on the same WSSB. You could attempt to take one by one on the Azure Service Bus, but then other services need to know how to communicate over ASB and WSSB as well. Potentially, having a middleware infrastructure that knows to send and recieve to/from both WSSB and ASB until you can disable the WSSB completely. The devil is in details, which for a clear reason cannot be shared here.
And there are also complications such as messages in flight that are sent in the future. Those need to be accounted for. I would recommend to turn to Microsoft support for some pointers, but be aware that the product is already out of support and they technically are not necessarily have to provide any assistence.
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 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.
I'm building a game for Windows Phone 8 and would like to use Windows Azure SQL Database for storing my users' data (mostly scores and rankings).
I have been reading Azure's documentation on SQL Database and found this link which describes just the scenario I'm looking for (it's Scenario B in the picture): I want my clients (the game running in a user's windows phone) to get data from an SQL Server through a middle application also hosted on Windows Azure.
By reading further the documentation (personally I think it's really messy and hard to find what you're looking for in there), I've learned that I could use Cloud Services for this middle application, however I'm not sure if I should use a background worker which provides an HTTP API or a worker with a Service Bus Relay (I discovered that I can use service bus in WP8 in this link).
I've got a few questions that I couldn't find an answer to:
1) What would be the "standard" way to go in this case?
2) If both ways are acceptable, are there other advantages to using a Service Bus other than an easier way to connect and send messages to my middle application? What are the disadvantages?
3) Is a cloud service really what I'm looking for (and not just a VM with the middle application code running in it)?
Its difficult to answer these sort of question as there are lots of considerations. I don't believe there is a necessarily 'standard way'.
The Service Bus' relay service's purpose is to help traverse firewalls and NATs, not something that directly relates to your scenario, I suspect.
The Service Bus, though, also includes a messaging capability which provides queues, topics and subscriptions to use to exchange messages between clients or client/server.
You could use the phone client to write and read messages to/from queues. you would then have a worker role hosting your application logic and accessing the database as needed.
Some of the advantages of using messaging include being load leveller, helping handling peaks in traffic (at the expense of latency), helping separating concerns and allowing you to accept requests from the clients when the backend is down as so can help with resiliency.
In theory they can also help you deliver messages to the client in the same fashion, by using a queue or subscription per client, but for a large number of clients this may become a management issue.
On the downside you would have to work with what is a proprietary protocol, and will need to understand the characteristics and limitations of the service bus. you will need to manage the queues and topics over time. there will also be some increased latency, although typically not an issue and, finally, you will have to implement asynchronous messaging on the client side which has advantages but is also harder to implement.
I would imagine that many architectures follow the WEB API route by using a web role cloud service exposing the API. The web role can then perform any business logic and connect to the database in the background.
A third option, which you didn't mention, is to use Windows Azure Mobile Services and implement your business logic as a service API there