6

According to the documentation, memory storage is intended for testing purposes only and should never be used in production. The only practical purpose I can think of for this might be state testing, such as with Serverspec or Inspec, to validate configurations. Using memory storage for this purpose might be a little faster and use less disk storage. I'm ...


5

Yes, but it's by preventing the things you mention in your question as much as possible. You are right that there are only so much developers that can work on the same code before things become unmanageable. You need someone or something that has an overview of all changes and makes sure integration works fine and regression doesn't occur. This is hard to ...


4

Well, you won't be able to apply an Agile methodology to a large team. One of usual principle is to work on Pizza Team (Less than 10 persons which can share a large pizza for diner together) because the lack of formalism advocated by Agile process makes it hardly applicable to a large team, the information would be scattered and some would be lost in the ...


4

As the number of developers working on the same branch increases the risk of breakages/blockages increases. Eventually a point is reached where on average by the time a breakage is fixed a new one appears While the first part of the sentence is probably statistically correct I disagree with the second. CI and integration branches cannot defeat GIGO (...


3

SaltStack provides a method for modifying grains and adding additional information to the grains dictionary in several different ways by either setting them in the /etc/salt/minion config and/or through the /etc/salt/grains file. For example: 1. add grains to the minion config. Note, simply include the grains key here: id: minion-07 grains: roles: - ...


3

We went from a large, monolithic backend application worked on by 100s of devs into docker based microservices, deployments using ansible and similar DevOps fluff. Here are some notes on the process: Determine the domain boundaries inside your monolithic app. Make sure calls between boundaries happen as less as possible (by call I mean either in-process ...


2

Personally I don't think using CasC itself will have any negative scalability impact. Fundamentally CasC means the actual config files are not hand-maintaned, instead they're auto-generated following version-controlled rules - which can be a lot more reliable. But once the config files are generated - the service using them functions just as it dit with ...


2

Yes, splitting the bigger team into smaller, agile-size sub-teams is obviously necessary. But it's far from sufficient to also be performant overall, at the bigger team level. With a highly scalable CI system in place it is possible even for very large teams to use trunk-based integration, in a single master branch, thus completely avoiding the intermediate ...


2

Docker and all the other fancy names are just tools. The examples are just examples. Resource-wise, Docker changes nothing much beyond usual Linx/Unix multiprocessing. It does not have the overhead of VMs, and little overhead over just starting the process directly ( https://stackoverflow.com/questions/21889053/what-is-the-runtime-performance-cost-of-a-...


2

Canary release/deployment is the term you are looking for. Usually in a canary deployment, a small percentage (10% for example) of your infrastructure is updated with the latest revisions of your codebase. That percentage is then tested with various automated and manual testing methods. Once testing is complete, the remaining 90% is updated with the same ...


1

I ended up following this path Rather than use cron, i used a scheduling framework (in my case Bree.js) which allowed me to "jobify" the tasks and also execute these tasks in separate processes - this allowed me the vertical expansion needed (ie: using more processor cores) A docker container contains the dispatch (scheduling) and jobs - so once ...


1

Redis Cluster could be considered as an OOTB solution for the Scalability requirements. There is another interesting open source library known as Redis Shard for sharding implementations on Redis. Please find the GitHub repository here.


1

Having a CasC setup means that you are in a better position to deal with any scalability issues that should arise later. It should take you a while to max out a nagios box. As long as you haven't starved it of memory or something you should be able to get thousands of nodes on a single nagios box. How many depends on how many checks you're doing and how ...


1

From my experience in managing a Nagios deployment with version controlled configuration files and CI/CD, it works really well. You can collaborate with other teams more easily since you can grant access to a git repository, and you gain all the benefits of CI/CD e.g. rollback and automatic testing. One thing that may be a bottleneck is how frequently you're ...


1

I've been working on couple of Agile projects with over 100 developers without any problems, so from my personal experience, to deal with such big workflow, here are some suggestions: Team definitely should to be split (max. ~12 people each). Make sure you've the right people with the right skills in each team, so they're independent (cross-functional ...


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