After reading Tensibai's excellent answer, I realised I used to be able to calculate this for network analysis purposes. I dug out my copy of High Availability Network Fundamentals by Chris Oggerino and had a crack at working this out from, not quite first principals.
Taking my serial example directly out of Tensibai's answer is simply a case of multiplying ...
I'd take that as a math problem with the SLA being the probability of being OK.
In this case we can rely on probability rules to get an overall.
For your first case the probability that App Service (A) and Sql Service (B) are down at the same time is the product of their probability:
P(A)*P(B) = 0.0005 * 0.0005 = 0,00000025
The probability that one of ...
I'd say the minimal viable configuration to test and get a good overview of pod placement would be 5 machines, 2 masters and 3 nodes.
This allows you to play with a master failure, placement of multiple pods "stretched" across the cluster, etc.
This is a simple thumb rule one could follow
Use version control (git, svn, cvs) for the work product created by humans
Use artifact management tool (artifactory, nexus, apache archiva) for the software bundle (artifacts) created by the system thru build or packaging process
HUMAN ==> System
GIT/SVN (build/packaging) ...
Version Control (using say Git) and Artifact Management (using Artifactory) are complementary. Version control is useful for easily browsing the historical changes and who made them. Artifact management tools can do this but it's clunky. Also they don't offer a fine grained view of changes, as one version change might involve a large amount of changes.
So what you have actually is this:
As your API ELB is in a private zone it can't be accessed from the internet.
Your frontend in React.js just run in User's browser and not on the UI servers, those server just serve static files.
You have two options, configure your frontend servers to redirect API calls to the API ELB or just update the API ELB to be ...
TL;DR: Measures of size can be split roughly in three different categories that I would define as depth in what you
manage vs. what you outsource or consume as a service, breadth of
services supported and height in numbers of instances,servers and
customers. Measures of complexity largely depend on selected
systems architecture, organizational ...
TL;DR Pick software that focuses on long-term support. Use containers so that you can separate the runtime you need for your app from the security patching of the underlying infrastructure.
I used to run some old PHP sites running popular content management systems. The plugins would fall out of support such that I could not upgrade the ...
Its very common to provide a StatusPage (like Statusy.co or StatusPage.io). There are numerous examples of major providers having them:
You could provide the same status page to your customers....
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 ...
"best suited" is the question. How do you measure this? what are the metrics and why do you choose them? I think you are looking for some kind of "tools combination", earlier tested on production by someone else's if preferred. What you want to do is try some opensource/free private cloud on-premises and run IaC on this private environment. You can test ...
There may be a significant speed difference between provisioning an environment and bringing up that environment. Especially when it comes to what you mentioned: IaaS and hybrid environments - those are VMs and bare metal servers - it may take many seconds/minutes for some of them to come up.
So there may still be value in patching those environments, ...
Your application requirements really do influence your options here, maybe add more detail about the app because this subject is very much about your application architecture too.
The application state is fixed, pod's are rebuilt as per the spec or source container that defines them and the replication sets take care of the deployment so I'd say the ...
The service can be always-on listening on the queue for jobs, or single-job started by the queue only when new work arrives.
The tradeoff is startup time for single-jobs vs cost for always-on service.
Define the requirements - number of jobs per day, max latency, ram/cpu needed, etc and then select the right technology that can deliver it in the most cost ...
Here's what I've tried:
Terraform + libvirt
There's unofficial libvirt provider for terraform. It works, but there are a few gotchas:
Doesn't support block devices:
Existing state not being removed:
Service Level Agreement
What will happen if the docker registry is down? Are all departments blocked? What is the impact?
This sounds like an asymmetric or n-path routing issue. Here is what is probably happening:
Machine A at IP address 192.168.1.1 makes initiates a [SYN] request through the LB at 192.168.1.10. the LB then proxies the payload to Machine B at 192.168.1.2, so the payload now has source: 192.168.1.1 and has has destination: 192.168.1.2 (which used to be 192.168....