19

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 ...


15

The term Phoenix Server was coined by a fellow of Martin Fowler, and all three terms described in short articles on Martin's bliki. Snowflake Server Phoenix Server Immutable Server 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 ...


15

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 ...


10

https://wiki.jenkins.io/display/JENKINS/Jenkins+Best+Practices 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 ...


9

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): Snowflakes Servers 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. ...


7

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 ...


6

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 ...


5

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 ...


4

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 ...


4

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 ...


3

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 ...


3

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 ...


3

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 ...


2

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. Snowflake Server 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 ...


1

We have two projects: production and staging. Later runs dev, qa also. And for billing purpose, we tag resources accordingly.


1

Linode is one of these (see linode.com). Linode offers 5$ ArchLinux and yesterday I talked with their staff and two staff members confirmed to me that they can't find any plans to stop supporting it in the future, so that's good. According to ArchLinux wiki here, Arch Linux is a full rolling release OS which is basically "true rolling release OS": Linux ...


1

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. Short answer: 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 ...


1

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. As ...


1

I was able to combine your two example files by first converting them to JSON. foo.json { "apiVersion": "extensions/v1beta1", "kind": "Ingress", "metadata": { "name": "nginx-ingress" }, "spec": { "tls": [ { "hosts": [ "foo.bar.com" ], "secretName": "tls-secret" } ], "rules": [ { ...


1

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. According to https://kubernetes.io/docs/concepts/services-networking/ingress/ one could update an existing ingress yaml and subsequently run kubectl replace -f. From a microservice ...


1

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. Reasons: stubborn, inexperienced, irrational 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 ...


1

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.


1

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. ...


Only top voted, non community-wiki answers of a minimum length are eligible