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 ...
The term Phoenix Server was coined by a fellow of Martin Fowler, and all three terms described in short articles on Martin's bliki.
The pros and cons of each such server are described in the articles. The main difference being in the way the server is managed.
Servers exist to fulfill the role of a ...
In larger systems, don't build on the master.
If you have a more complex security setup that allows some users to
only configure jobs, but not administer Jenkins, you need to prevent
them from running builds on the master node, otherwise they have
unrestricted access into the ...
"Serverless" mostly just means you've got relatively simple microservices, generally just a little webapp or a single function that is automatically connected to a REST frontend. The same concepts apply as you would use for a more traditional web services: usually some mix of remote syslog and ElasticSearch writers.
Networked or remote syslog has been ...
As I was more thinking of a listing of advantages and drawbacks of each type, here's is my view (not exhaustive, it's the important operational ones in my opinion):
What they are: Systems with their specific configuration, no other servers in the data centre have the exact same parameters. They are usually manually administered.
Are they separate projects (from a logical or technical perspective)? Would one ever need to be updated/recreated independently of the other one? Would they need to scale independently of each other? I think if any of those answers is a yes, then they should be separated. If not, you should be fine bundling them together. Bundling them together will reduce ...
Make sure that your stories are not centered on Operations. Remember that DevOps is a culture not a role. Is an "Operations Engineer" really the stakeholder for the story?
Think of the features and business value they provide. As a stakeholder I want feature so that business value. If you are struggling to identify the business value why are you doing it?
Different approaches can be useful for different setups. You can use tags in some cases, or conditional includes (as you describe) in other cases.
On the other hand, it generates quite a payload of “skipped” tasks in ansible logs, which raises a red sign to me.
You should get familiar with difference between static and dynamic includes in Ansible.
So if ...
So still not benchmarked much, but after a quick code inspection and a bunch of reading about netty and logstash in version 5 the input is not the bottleneck to worry about.
Logstash team did put a bunch of work in the way the filters and outputs plugins are run in parallel, the beats input plugin wait for a batch of events, and the performances problem ...
This answer is more about scalability considerations - if the number of workers can be high and/or multiple of them can produce logs at high rate at the same time.
Yes, using multiple logfiles simultaneously is a good practice.
Attempting to combine into a single logfile logs from multiple workers in real time will raise problems:
using blocking mechanims ...
There are some situations where running jobs on the master node is fine, but you do have to be careful. Like the other answer mentioned, generally speaking running jobs on the master is bad practice since the jobs aren't sandboxed on the master node.
That being said, sometimes you do want to run jobs on the master node. For instance, two of the jobs on my ...
Speaking primarily from the Google App Engine (GAE) perspective.
My preference is for environment-driven project split. This might be of interest: Advantages of implementing CI/CD environments at GAE project/app level vs service/module level?
I wouldn't go for architecturally-driven project split unless there are serious reasons for doing so (if you feel ...
The general design pattern is one container = one running service - see the initial comment at https://docs.docker.com/config/containers/multi-service_container/
Now, after spending about a year developing a multi-service application relying heavily on docker this is what works for me:
Avoid creating files inside the container unless it is your storage ...
I would say It depend on you preference since redeploying a stack for only 1 or so image, will not restart all the containers present.
In the other hand network feature since docker 17.06 are reusable between stack with the attachable mode so you could easily separate the layers of your app while keeping them on the same sub-network (for usage like traefik ...
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 ...
All three are patterns of sorts, it isn't is a case of picking and choosing which to use in any specific circumstance but a case of knowing when to recognise the patterns that can help or hurt you.
A Snowflake Server is very much an anti-pattern representing the case when a server evolves in an uncontrolled manner to the point when it ...
Google's recommended best practice is to create an Organisation within GCP so that you get access to folders, then model the hierarchy of your organisation within GCP:
there should only be one organisation that represents the entire organisation; configuring directory sync is very painful otherwise.
folders should represent business ...
We always use different container for each service (Like Frontend ,Backend and Database). Because a container can run only a single service inside it at a time by using docker-compose.yml file. But we can define multiple services inside one docker-compose.yml file but one for each container.
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.
I was able to combine your two example files by first converting them to JSON.
While I can't find it explicitly written anywhere, I do know that textbooks frequently reference that you can use the free tier to avoid costs, and that they frequently have you create and destroy instances between chapters. So, I find it extremely hard to believe that you would get billed for deleting and creating new EBS volumes.
So, I believe that if ...
You can follow below approach:
Use Cluster Autoscaler which should scale-in or scale-out nodes as and when required.
Create nodegroups with multiple instance types so that you always get a spot node.
Use labels and anti-affinity rules to schedule applications on any of these available spot nodes.
There is a balancing act here between the simplicity and maintainability of your solution, and how auditable creating separate service principals or users for each of your external customers. I suspect only you can actually decide which is the best practice in your specific legal and regulatory situation.
On the side of having a single Service Principal ...
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 ...
Could I have these two different definitions which creates a single
Ingress with two rules (based on having the same name)?
Lets investigate whether that would be possible.
one could update an existing ingress yaml and subsequently run kubectl replace -f. From a microservice ...
The last couple of years I am/was part of couple of DevOps teams that are/were creating microservices. Some of the projects failed miserably.
architect that only read a blog about microservices and claims that he is the expert of microservices
team members that lack knowledge, but indicate that they know everything about it as the architect told ...
From my point of view, you can design microservices just like classes in an application. That is, you are looking for maximum cohesion within a service. In other words, all stuff inside one microservice should work together to achieve exactly one well-defined responsibility, and no other microservice should have any content for the same responsibility.