As a organisation, we have 100+ services running at the same time, to keep the company functioning (namely software applications to assists the HR, Finance, Purchasing, Estate, Services, payroll, etc....)
our main focus is to look after the integrations between those services, so they can functioning as a single unit, rather than a list of isolated applications
LDAP, Oracle Database, SOAP webservices, tomcat based webApps are our critical services, we are currently looking at a service monitoring and discovery tool to manage those services
my questions is with our in house webApps or webservices, through the consul java API its fairly easy to register with the Consul server, and implement a health check mechanism. I found its difficult to register and monitoring other services such as LDAP, database or 3rd party SOAP services
anyone can share some examples or point me to the right directions please.
Use an external address in your service definition. For example, suppose you had an external LDAP server that you wanted to run a TCP check against:
{
"service": {
"name": "ldap",
"port": 4432,
"checks": [
{
"tcp": "my-ldap.example.org:4432",
"interval": "10s"
}
]
}
}
You could then query consul at ldap.service.consul. Be sure to look into prepared queries and the nearest attribute.
Related
I was looking at 12 factor app principle and saw this statement. I believe this statement states that the application must respond to any backing service such database or message broker and connect to them irrespective of what they are. How does it differ from traditional way of connecting? For eg: in my microservice , I was defined database and kafka broker as user provided service in cloud foundry. It just provides the connection parameters as vcap service variables. I still have code to connect to a database and kafka broker which are entirely different. What does this statement signify and how does it differ from what we do in non-cloud environment?
As stated in the below article:
https://12factor.net/backing-services
It states that :
A backing service is any service the app consumes over the network as part of its normal operation. Examples include datastores (such as MySQL or CouchDB), messaging/queueing systems (such as RabbitMQ or Beanstalkd), SMTP services for outbound email (such as Postfix), and caching systems (such as Memcached).
Microservice can connect to any backing service irrespective of the platform. In PCF, you are binding services to your microservices to connect. In other cloud environment, you can point to any backing service like AWS RDS or other services provided by the Platform.
The real difference is this :
Backing services like the database are traditionally managed by the same systems administrators as the app’s runtime deploy. In addition to these locally-managed services, the app may also have services provided and managed by third parties. Resources can be attached and detached to deploys at will. For example, if the app’s database is misbehaving due to a hardware issue, the app’s administrator might spin up a new database server restored from a recent backup. The current production database could be detached, and the new database attached – all without any code changes.
I have written a web application that is, typically, installed internally by customers (based on IIS/MSSQL server).
When a customer wants to provide external access to the application, we offer the following supported scenarios:
Publish the application in their DMZ (pretty standard deployment).
Use our own platform where we host the application in our own cloud infrastructure for them.
However, because I have more and more customers who misunderstand the requirements for publishing an internal application, I would like to add a "one click" way of providing that service.
My idea is to have a reverse proxy installed on the customer's web server that will connect to a cloud server we control. When the application starts, it will connect to our server, authenticate and maintain the connection. When a user wants to use the application, she will use an URL that directs it to our server (say https://myapp.mycompany.org/CustomerID or https://CustomerID.myapp.mycompany.org). The server will then lookup the list of connections from reverse proxy to find the one matching the customer ID and, if found, use that connection to relay the end user connection.
In essence, that is the same thing as what Azure Application proxy or TeamViewer do, only without the need for using Azure AD or TeamViewer.
Is there an existing framework I can use for building such a service ? I know I can write it on my own but that is quite a large development.
I am working on a program that uses Azure for it's database. It works pretty good, except that I have to authorize every IP address that I access it from. So, if I go to a friends house I have to authorize that IP, and if I go to a coffee shop I have to authorize that IP...
I am hoping that there is a way to authorize the connection from the program, whatever IP it is coming from. Or, worse case senario, turn off that security measure.
DON'T.
The idea behind Firewalling your DB is to protect your data from anything that could have the SQL Server credentials should they somehow leak. It's for your own safety.
Instead, try to write a quick Web Service with ASP.Net WS/Jax RS/Rails/... to expose the DB data in a sane, secure and thoughtful manner. It's not hard and there are tons of tutorials and books on the matter out there.
Although NOT Recommended, but if you want to turn off this security measure you can allow connections to your SQL database from all IP Addresses by setting the IP address range to 0.0.0.0 - 255.255.255.255 in Azure Portal.
Another alternative would be to dynamically manage allowed IP addresses by using Azure Service Management API. You can manage Firewall rules using this API. You can read more about it here: http://msdn.microsoft.com/en-us/library/azure/dn505717.aspx
So what you could do is have a small service running in Azure. When your application starts, it sends the current IP address to your service and your service sets the IP address in the firewall rules. When the application terminates, it sends another request to your service and then your service removes that IP address from the firewall rule.
As #Machinarius so eloquently said DON'T. .NET already has a way of exposing data through OData services. You get SOAP or Json, LINQ queries, caching, security even down to the entity or operation level.
Exposing an EF model as an OData service is very easy. You can create an ASP.NET Web API OData endpoint using the "Web API 2 OData Controller with actions, using Entity Framework" template as described in the "Creating an OData Endpoint" tutorial.
To call the service from a client, you add a service reference to it and then use the proxy to execute LINQ queries. It could be something as simple as:
Uri uri = new Uri("http://localhost:1234/odata/");
var container = new ProductService.Container(uri);
var myProducts=container.Products.Where(....);
Check "Calling an OData Service From a .NET Client" for a detailed tutorial.
As an alternative, if you need to access your application from random places, why not have a VM configured in Azure with your application installed. And whenever you need your app, fire up that VM, RDP there and work via RDP. Would not need to update connection and much more secure rather then having to allow random IPs to access your database.
I realise this is not an answer to your question, but other stackoverflowers already provided a significant input on your problem. And I do agree with them all. Do not disable the firewall. It is for your own good!
I am kind of new to system architecture. That is, all of my web apps have been relatively flat...two machines at the most running web client and database.
I have been handed the following architecture:
1 VMware machine will run the web application, an MVC 3 app.
1 VMWare machine will host the SQL Server database
1 VMWare machine will host the services.
The machine I'm confused about is the last one. From what I understand, the services project contains references to three other projects: the model, where the entity framework edmx resides, the entities project, which contains T4 templates that use the entity edmx file as input, and the business project which is where the actual business rules are implemented and the meat of the CRUD actions take place.
From what I understand, the intent is to not run an IIS WCF web services interface, but to make calls to WCF services (like those hosted in the MMC services snap in) on the machine over the internet. There is a deployment project in the solution for the services project but I don't know if it's configured properly. I think the idea is to just run the installer on the services machine and it will work.
My specific question is if there are any important things that I need to keep in mind when implementing, configuring, and deploying these services?
I'm kind of new to all of this. I was under the impression that you had to make calls to WCF services via IIS hosted endpoints and that you couldn't (or it at least was inadvisable) to make what amounts to RPC-like calls to machines over the internet.
Since you are new to WCF services, I suggest reading this MSDN article on Hosting and Consuming WCF services.
From what you describe, it looks like you are using Windows Service as a host for your WCF service.
The most common choice for a host is IIS because of its extensive features including self-starting services, ease of deployment, load balancing and so on.
Windows Service is a valid host, provided you can justify the question 'Why not IIS?'. Maybe, you need full control over the activation and lifetime of your WCF service. Not sure.
p.s. Ensure the account that your Windows Service runs under, has the minimum privileges.
Real application how can i use this app fabric ??
How can i put my business logic in this and this logic use in my windows azure application??
Thanks
The Azure AppFabric is a collection of services that allow to you leverage functionality traditionally provided on premise by infrasture components common to most networks. Currently, it consists of the following:
Azure AppFabric Service Bus - allows for connection of applications by providing a centralized relay point in the cloud. Applications create outbound connections to the rendezvous location, thus helping mitigate the challenges posed by security measures like firewall restrictions on in-bound connections and IP masking via NAT layers. This feature includes both 'real time' options as well a 'message buffer' dynamic to allow for more disconnected style communication.
Azure AppFabric Access Control Service - the "ACS" allows WIF applications to quickly access various identity providers and consume a single format of claims token. Used in conjunction with products like ADFS, it allows cloud hosted applications to authenticate against on-premise identity stores.
Azure AppFabric Cache Service - currently in public testing, this service brings the "Velocity" style functionality to applications. This provides them with a distributed cache system as well as a new session provider.
There's more features/services coming in 2011, but these are the hot ones currently. Regarding hosting your business logic, this is not something that is currently available in the Azure AppFabric. There's been mentions that we may eventually see the potential for placing applications "on the edge", meaning the servers that front the Azure AppFabric connections, but no ETA or even firm commitment that this will happen.
You can implement your business logic in Windows Azure, in a web or worker role depending if you need it to be synchronous or asynchronous.
You can surface the business logic using the service bus, though you could also implement your logic on premise and surface them via the service bus.
AppFabric is not a business logic layer. Think of AppFabric as cross-cuts, or glue between different parts of your application.
For now Business logic goes in components like a web or worker role, or an on premise app which you could expose on the internet using AppFabric Service Bus.
In a future release, AppFabric will release "Composite Apps" which in a nutshell seem to allow you to deploy managed WCF/WF workflow services, which makes for a better "business engine". But for now I think you could probably just use Workflow services in a web role.