We're looking into how we could manage the configuration of several microservices (10 - 15 services) and fat client applications which are installed in equipment (several hundreds). The applications are being developed in Java (for what it's worth). The equipment doesn't always have a working connection to the network, so the configuration must also be cached locally.
We have been looking in to Spring Cloud Config and services such as Consul, Zookeeper and Etcd. We particularly like Consul as it comes with a lot of functionality out-of-the-box, not in the latest a user interface.
What we are still struggling with is how we should setup such a tool especially for the equipment configuration. We have four different types of equipment which can be running slightly different versions of their respective applications. These applications share some configuration settings, whereas other settings are specific to a version, an equipment type or even a single equipment.
It seems pretty easy to store the configuration for one version of a single type in a tool like Consul, but how could we structure the settings in Consul for the environment we have in such a way that it is still clear and understandable for service engineers who shouldn't be too familiar with all the intricacies of the application? Is Consul actually the right tool for this?
I'm uncertain if you want to simplify your configuration management that you can reuse anytime.
You might want to check out some popular Key-Value Management software such as Hashicorp Vault, AWS Secret Manager, Bitnami Sealed Secrets, and others.
Cheers!
I have a front-end in vue.js and back-end API in laravel. I am curious about environments. I will write down my idea and let me know if it's the right one.
we could have development, staging and production environments. So this means front-end will need 2 servers. 1 for staging, 1 for production. For API, we also need 2 servers. staging server will have different database and production will have different database. So 4 servers overal.
So do you think 4 servers are a way to go?
You just need 2 actually. Staging and development's front-end should come with the API. Then production's front-end and API should come together. You don't really need separate servers for back-end and front-end, just separate environments. Also it will depend on how you will set it up. In fact, all can go in one server in different docker containers.
We have multiple environments for our apps, but not all apps have the same environments. For example:
App 1 has dev, qa, and prod environments
App 2 has dev, and prod environments (no qa environment)
We're trying to figure out if there's a simple way to route requests cross-environment so that App 1 in qa has access to App 2's services in dev. The solution that seems to make sense is a way for apps to register with more than one Eureka instance, so that they are discoverable by apps connected to either Eureka. Of course the potential problem there is that how does App 2 know which Eureka to use for its own discovery, but let's assume that App 2 makes no external calls.
Is there a simple way to accomplish this out of the box with Spring Cloud?
The alternate solution I am considering is spinning up additional instances of App 2 to create a qa environment that's just based on the dev environment's code. That would obviously work, but then it's additional instances to maintain and I am hoping there's another way to handle it.
If I have two servers. One in the USA and one in Europe.
How would I use Cloudfoundry on those?
Do I simply deploy a single Cloud Foundry Instance on those two servers?
Am I able to push an app to a specific server? (say I want two instances in Europe and one in the US)
And will CF then redirect requests from different locations to the nearest server?
If I was to set up two different CF Instances, (One in the US and one in Europe), would they be able to cooperate?
This is possible, you can search for "Cloud Foundry multiple datacenters" or other such terms to see how different users have implemented this. One good starting resource is this presentation. There are all sorts of trade-offs to be made when doing such a setup, so there is not just a single solution. Also, this proposal will bring one particular solution into the core of OSS CF.
My application contains 25 C# projects, these projects are divided into 5 solutions.
Now I want to migrate these projects to run under Windows Azure, I realized that I should create one solution that contains all my web roles and worker roles.
Is this the correct way to do so, or still I can divide my projects into several solution.
The Projects are as shown below:
One Web application.
5 Windows Services.
The others are all class libraries.
Great answers by others. Let me add a bit more about one vs. many hosted services: If the Web and Worker roles need to interact directly (e.g. via TCP connection from Web role instance to a specific worker role instance), then those roles really should be placed in the same hosted service. External to the deployment, your hosted service listeners (web, wcf, etc.) are accessed by IP+Port; you cannot access a specific instance unless you also enable Azure Connect (VPN).
If your Web and Worker roles interact via Azure Queues or Service Bus, then have the option of deploying them to separate hosted services and still have the ability to communicate between them.
The most important question is: How many of these 25 projects are actual WebSites/Web Applications or Windows Services, and how many of them are just Class Libraries.
For the Class Libraries, you do not have to convert anything.
Now for the Cloud project(s). You have to decide how many hosted services you will create. You can read my blog post to get familiar with terms like "Hosted Service", "Role", "Role Instance", if you need to.
Once you decided your cloud structure - the number of hosted services and roles per each service, you can create a new solution for each hosted service.
You can also decide that you can host multiple web sites into a single WebRole, which is totally supported and possible, since WebRoles run in full IIS environment since SDK 1.3. You read more about hosting multiple web sites in single web role here and here, and even use the Windows Azure Accelerator for Web Roles.
If you have multiple windows services, or a background worker processes, you can combine them into a single Worker Role, or define a worker role for each separate worker process should you desire separate elasticity for each process, or your worker require a lot of computing power and memory.
UPDATE with regards to question update:
So, the Web Application is clear - it goes to one Web Role. Now for the Windows Services. There are two main considerations that you have to answer in order to find whether to put them into a single or more worker roles:
Does any of your Windows Services require excessive resources (i.e. a lot of computing power, or
lot of RAM)?
Does any of your Windows Services require independent scale?
If the answer for any of the questions is "yes", then put this Windows Service in a single Worker Role. Put all the Windows Services that the answer for both questions is "no" in a single Worker Role. That means that you will scale all of them or none of them (by manipulating the number of instances).
As for Cloud Service (or the Hosted Service), it is up to you to decide whether to use a single cloud service to deploy all the roles (Web and Workers) or use one Hosted service to deploy the Web Role and another one to deploy the Worker Roles. There is absolutelly no difference from billing prospective. You will still have your Web Role and Worker Role(s), and you will be charged based on instances count and data traffic. And you can independently scale any role (change the number of instances for a particular role) regardless of its deployment (within the same hosted service, or another hosted service).
At the end I suggest that you have single solution per Hosted Service (Cloud Project). So if you decide to have the Web Role and Worker Roles into a single Hosted Service, than you will have a single solution. If you have two Hosted Services (Cloud Projects), you will have two solutions.
Hope this helps.
You are correct ! and all projects goes to under 1 hosted service if you create only one cloud project for all your webrole and worker role project
Still you can divide your projects into several solution and you have to create that much cloud project and hosted service on azure platform
You can do both.
You can keep your 5 separate solutions as they are. Then, create a new solution that contains all 25 projects.
Which solution you choose to contain your Cloud (ccproj) project(s) will depend on how you want to distribute your application.
Each CCPROJ corresponds to 1 hosted service. So you could put all of your webs and workers into a single hosted service. Or you could have each web role as a different hosted service, and all of your worker roles together on another hosted service. Or you could do a combination of these. A definitive answer would require more information about your application, but in VS, a project can belong to more than 1 solution.