The three major cloud platforms you mentioned have either free trials or a free tier; these all include spending and resource caps which prevent you from spending more than your free trial allows:
Azure offer £150/$200/€170 for the first one month of usage, in addition many of Azure's services have a free or low cost tier:
App Service Free Tier
Emulate the cloud on your own hardware
Doing anything substantial with the free tier is challenging. But you probably have some hardware lying around that you can build your own minicloud on. If you need more memory you can dig through your junk drawer. If you build something serious there's some chance you'll decide to buy more hardware, but that is ...
I would set up a base taxonomy to start with, you can use automation across your estate to ensure that all resources follow the taxonomy. You have a choice between simply deleting resources that don't comply or reporting on it to a central team who are responsible for chasing down and educating the owners.
I have followed the Best Practice set out by ...
I think have found out why this graph looks like this.
I am also gathering metrics for the ASP.NET Applications / Errors Total performance counter, and I have noticed that exactly at the same time that a memory available surge happens, the Total Errors metric resets to 0.
According to msdn this counter resets to 0 everytime an application restart/shutdown ...
I've seen this same "sawtooth" pattern in other systems, in particular a Java-based data tool. Based on your description, I think you're looking at .NET garbage collection (assuming this is a .NET app.) Java and .NET are both memory-managed languages and frameworks that use garbage collection.
A memory leak is typically found in frameworks that lack ...
The benefits as I see them are the general reasons to use Azure Key Vault
Secrets are centrally stored with options for authorization, auditing, etc.
Azure can be scripted to update the secrets on a timer - so in case a connection string gets in to the wrong hands, it is only valid for a day (or a week, or whatever)
In case the secret is shared between ...
Use a Git post-receive hook to issue a git pull in the directory you want to keep updated. You might want to mount the directory you want to keep updated locally to the Git server, or execute that command remotely with ssh into Git Bash on Windows, or Powershell. Alternatively have the hook call a webhook and have the webhook execute the git pull. The ...
Azure Container Instances
(ACI) may be a good option as you suggest. These let you run a container directly on Azure, without having to manage a VM, with per-second billing for the time the container is used.
Although one of the demos on that blog mentions Kubernetes, the idea of ACI is that you can create a container through the Azure CLI with az ...
There are quite a few services that offer 'free tiers' of some description to help new developers get started with a cloud platform without the cost you've mentioned.
AWS have quite a generous free tier:
1 million free Lambda requests/month
25 GB of DynamoDB storage
20,000 free requests to the AWS Key Management Service
Go with a separate logical server:
It is going to cost the same because you are charged on the tier of the database not the database server.
By providing separate servers you provide isolation between the two databases protecting one from the other.
Unless you use contained users your users will be shared between Test and Production, if you happen to use ...
Putting them both on the same server is certainly the easiest. However, I'd argue in a business situation you shouldn't be able to do it.
A production database is one of the most important resources of a web app. It likely has much confidential data in it. It's also probably critical to the site's stability. So the production database credentials should be ...
The article you are referencing mentions encrypted RAM but that was only a reference to possibilities of enhancing the technology more in the future, not about the current state of confidential computing.
Confidential computing means, that when data is in use these things are prevented:
Malicious insiders with administrative privilege or direct access ...
The standard pattern for this is to have a build that is triggered upon change to the git repository. The build will do nothing more than checkout the repository and make an archive of everything but the .git folder, then upload that to whatever file server(s) make(s) it available to all the things that need it. Implementation specifics depend on the git ...
Azure has a robust CI/CD pipeline which is much easier to use than CodeDeploy on AWS. It is called Build/Release pipelines under Azure DevOps. It allows you to configure multiple environments with build and release (deployment) stages for each. It also allows for easy configuration and interoperability with Azure Webapps/VMs and other resources available on ...
Virtual Machine Scale Sets (VMSSs) don't have a SLA of their own:
Virtual Machine Scale Sets is a free service, therefore, it does not have a financially backed SLA itself. However, if the Virtual Machine Scale Sets includes Virtual Machines in at least 2 Fault Domains, the availability of the underlying Virtual Machines SLA for two or more instances ...
I am less familiar with what Azure offers, but other cloud providers offer a way to manage users external to the VMs the provide (normally IAM permissions).
I would not bake user into the system but look for an external way to manage them. This allows you to more easily remove users that leave your company or add new users that join.
If Azure doesn't ...
I would agree with previous statements: avoid baking users into your base image with Packer. Likewise, you should avoid baking them with Terraform as well. Terraform does not provide a mechanism to perform on-going changes after the server is provisioned. It only has those initial provisioning scripts that get run only one time. If you manage users with ...
The prerequisites for a chef server are here and common to any installation.
You only need to allow https to port 443 from your inner infrastructure to the cloud server.
If you have a proxy with SSL interception I'd recommend adding this proxy certificate to each client cacert.pem and set an environment variable SSL_CERT_FILE=<chef_install_path>...
For an alternative approach, I would investigate Azure functions:
No VM continually running.
I avoid "baking" user accounts into my OS image with Packer unless there is an OS specific need for it. For example, a service or system account that is needed across all of my deployments.
My suggestion is to use a Terraform provisioner to create the user accounts. That way you can change them when deploying the VMs via Terraform without having to create ...
'Suitable' can honestly be whatever works for you. I personally feel its perfectly reasonable to do a manual install of Chef server. It is the CM tool to help provision the rest of your fleet. You will not be setting up Chef server over and over again. You do it once, and then never again, in theory.
That theory breaks down however, in respect to server ...
The B-series has this name from burstable adjective.
It means that you do not have 100% of the cores for 100% of the time (see Introducing B-Series, our new burstable VM size).
For example B-2 you have guaranteed only 40% out of a potential 200%.
The suggestion to pick a different serie for production workload, is to guarantee the CPU available.
Found this --> Passing secrets to a Docker container
Environment variables appear the preferred method - will need to run a prebuild script to fetch the secrets and then follow this
@Mods feel free to close as a duplicate
Not a stupid question, but it's lacking details. If by stack you mean Terraform, Vault, Consul etc, then you would go about provisioning machines/VMs/containers for those services likely using some form of ansible or equivalent.
It would be prudent to store those scripts in git or any other source control system.
Like, for example, should I just be ...
just create an ingress resource along side each application, that way you can modify individual ingress resources without impacting other applications. Load balancers do not allow you to do anything meaningful with your traffic.
With ingress you can use cert-manager, external-dns, ssl offloading, etc.
I could talk a lot about the architecture yet this is a devops community so I will addresses your main concern about running the database only.
If you were to modify the design to say "Azure SQL" for each microservice then it would look okay to me. Each microservice can have its own separate Azure SQL database instance (likely running on a ...
My largest concern is around the MS SQL Server implementation. Coupling the read only instances so tightly to the services feels wrong. Is there a better way to do this?
Essentially what you have designed is a caching system - the service containers have a local copy of the data presumably so that for reads they don't have to make an extra network trip.
There is no difference on vsts for your test (unit, integrated or functional). You just set the right dll name with your tests:
or select Test plan if you have a test plan with associated test recordings
I have the same opinion as you, I see no point in using the Key Vault in such scenarios.
Instead I utilize Azure App Configuration https://docs.microsoft.com/en-us/azure/azure-app-configuration/overview , where I simply store all application settings.
And the only string I store together within the actual app service/ func/ web job, would be the connection ...
I agree with others not to bake user accounts into the OS images. Especially personal user accounts of your infrastructure team should be maintained with a decent user management. There are only very rare circumstances where you want to system/service account to be installed everywhere.
Getting users into the systems is most times easy because ...