Referred Link - http://bigdataanalyticsnews.com/mongodb-mistakes-to-avoid-the-best-practices-to-follow/
MongoDB is supposed to be a greatly-in-demand NoSQL database. As per experts, developers are used to making many mistakes while working on various MongoDB projects. Here are some of the mistakes to avoid.
Mistake No.1: Allowing Access from the Internet
If you allow access to your MongoDB database from the Internet, it would be a grave mistake. The default configuration of MongoDB used to leave the database fully exposed to the Internet. It implies that anyone could easily connect to your MongoDB database simply by using the server’s URL. A database must be accessible through your app only. It must actually be kept hidden in an exclusively private network which would be local and providing access to only your app’s server.
Even though MongoDB developers claim that this sort of vulnerability no longer exists and has actually been fixed in the latest versions, you must ensure that the configuration is changed after upgrading the database from the earlier version. You must focus on securing your MongoDB database. Maintaining a white-list of only those IP addresses which are having access to your MongoDB database is supposed to be a clever idea.
Mistake No.2: Having Just a Single MongoDB User
Another probable security risk would be having just one MongoDB database user instead of multiple users doing the entire job. This generally would take place when inexperienced developers or developers with lack of any interest in databases or developers without sound knowledge of the databases are there to take care of database management.
It is always a bad idea to have just one user for managing the database and then utilize the same user for accessing the database. You must understand that NoSQL would not automatically imply “secure” by default. Developers must be concerned about security breaches and overall security of the database while creating the database. Do not wait until the last moment for properly managing security issues and mitigating all possibilities of security breaches after shipping the product. You may seek assistance from professional DBA services such as RemoteDBA.com for perfect database management solutions.
Mistake No.3: Assuming Schema-Less Implies No Schema
MongoDB does not necessarily require a schema. You need to focus on your data structure. Do not be impatient and do not be in a hurry, instead think how you would be organizing your data and structure all important documents. Schemaless does not imply you have absolutely no Schema. RDBMS generally boast a pre-defined schema that is tables with columns and each comes with a data type and names. If you wish to insert an additional column, you need to include an extra column to the whole table.
But MongoDB actually does away with all this. We discover the absence of any enforced schema per document or collection. This would facilitate rapid developments and modifications could become quite easy. But do not be under the wrong impression that you could completely ignore schema design. If you have a perfectly designed schema, you could obtain the best performance and outcomes from MongoDB.
Mistake No.4: Premature Sharding
Sharding is supposed to be an optimization. Hence, you must avoid doing it way too soon as it could be a bad idea. Often just one single replica set could be adequate for operating a smooth and fast MongoDB that caters to all your specific requirements. Bad indexing and bad schema are supposed to be the real performance bottlenecks that users would be thinking of solving their issues with sharding. This process could be considered particularly when an obvious resource such as concurrency or RAM becomes a performance bottleneck on some particular machine.
Mistake No.4: Using Replicas as Backup
Remember replicas are not supposed to be backups. You would be requiring the right backup system for your database. You must not regard replicas as the actual backup mechanism. Think about what would be happening when you end up deploying the incorrect code which totally ruins the database. In such a case, replicas would be simply following the master and having the same kind of damage. You could be using a backdrop and even restoring your MongoDB in a number of effective ways, such as Mongodump, or filesystem snapshots or even MMS (Third-party service). It is crucial to have perfect fire drills. You must have the confidence that the backups made by you would be used actually in a real-life situation.
MongoDB Best Practices
If you fail to follow MongoDB best practices you could end up losing sensitive data, disrupting operations, and even dragging organizations out of business. All the MongoDB best practices discussed below are from experienced MongoDB professionals involved in creating security systems meant for databases and working closely with MongoDB users.
Enabling Access Control plus Enforcing Authentication
You should be enabling access control and specifying the authentication mechanism. You could consider using any of the existing external frameworks or the default MongoDB mechanism for authentication. Authentication necessitates that all servers and clients must provide valid credentials and only then they could be connecting to the system.
Encrypting Communication
You must necessarily configure MongoDB for using TLS/SSL meant for all the outgoing and incoming connections.
Restricting Network Exposure
Make sure that MongoDB operates in a trustworthy network environment. Consider restricting or limiting the interfaces where MongoDB instances actually are listening for incoming connections. You must only let trusted clients go ahead with accessing the ports and network interfaces where MongoDB instance could be available.
Auditing System Activity
You must be tracking access and modifications to the database configurations, as well as, data. MongoDB Enterprise actually includes an efficient system auditing facility which could be recording system events like connection events, user operations, etc. All these audit records would be permitting forensic analysis and allowing administrators to go about verifying proper controls.
Considering Security Standards Compliance
You could take note of the Security Reference Architecture of MongoDB for learning more about ways to utilize the core security capabilities for building compliant application infrastructure.
Conclusion
Many people do not like MongoDB. Actually, this is simply because they are misguided. The fact remains that many of you lack the basic understanding. If you avoid the common MongoDB mistakes and follow the MongoDB best practices discussed above, everyone would be benefitting from the simplicity and power of MongoDB. Moreover, never disregard security best practices. The most certain way of creating an insecure system would be to go on ignoring the topic altogether. Before deployment of any MongoDB instance having certain sensitive data, you must examine thoroughly the MongoDB security.
Referred Link - https://www.mountaingoatsoftware.com/blog/what-happens-when-during-a-sprint
Sprint planning marks the official start of the sprint. Once this ceremony starts, so has the sprint.
The Scrum Master, product owner, and development team all participate. Others may attend on rare occasions when the product owner and team both agree it’s appropriate. For example, if the coming sprint will include developing functionality best explained by a subject matter expert (who is not the product owner), it can be useful to have that person attend. Usually, however, that type of discussion is best conducted outside the actual planning meeting.
The length of the sprint planning ceremony is proportional to the length of the sprint. A four-week sprint should be planned in no more than 8 hours. A one-week sprint should be planned in no more than two hours.
These are time boxes (maximums). I recommend teams target completing sprint planning in about half the allowable time box.
As input into the sprint planning ceremony, the Scrum Master will bring data on the team’s average velocity and most recent velocity. The product owner will bring the product backlog, or at least the highest priority items on the product backlog. On many teams, the product owner will also supply a draft sprint goal, which may be collaboratively revised through the planning process.
The outputs of sprint planning include a team that is smarter about and better prepared for the upcoming work. Additional outputs include a sprint backlog and an agreed upon sprint goal.
The daily scrum, also known as the daily standup, is a short, daily ceremony during which team members synchronize effort. Daily scrums enable team members to ensure the right things are being worked on by the right people at the right time.
Each day, each participant addresses three topics:
Questions can be phrased in any number of ways. For example, many teams find it beneficial for participants to describe what was accomplished rather than what they did.
Participants include the Scrum Master, development team, and, in my opinion, the product owner.
There is some debate within the Scrum community about whether the product owner should participate. Excusing the product owner from the daily scrum creates a separation within the overall team. Us-and-them feelings exist already in too many organizations. I don’t know why a Scrum team or its product owner would want to do anything to further enhance that negative attitude.
Each daily scrum is limited to 15 minutes. The intent is for it to be a brief update and synchronization effort. Unlike sprint planning, I don’t recommend trying to complete a daily scrum in half the recommended timebox. For most teams, 5-7 minutes is simply not enough time to raise any real issues or understand the work being accomplished. When teams shorten the daily scrums too much, the ceremony devolves into a series of rote updates, such as “Yesterday I did such-and-such. Today I’ll do this-and-that. Nothing is in my way.”
There are no formal inputs to the daily scrum. The only output is increased coordination of work by the development team.
The sprint review happens on the last day of the sprint. It should be attended by the product owner, Scrum Master, the development team and any appropriate stakeholders. The stakeholder participants may vary from sprint to sprint based on what has been delivered.
The sprint review is time boxed to a maximum of four hours for a four-week sprint. It is proportionately shorter for shorter sprints, down to one hour for a one-week sprint.
As input to the sprint review, the team should show all of the product backlog items that meet the team’s definition of done. This means that the team does not show work that is still in process. Sometimes, however, it may be worth making an exception to this rule.
The demo of finished functionality is the central activity of a typical sprint review. But most teams will also take time to discuss progress and problems. You can read about my recommended agenda for the sprint review.
The goal of the review is to solicit feedback on what was built during the sprint. The product owner considers all feedback and can make changes to the product backlog as appropriate. The output of a sprint review is therefore a revised product backlog.
The sprint retrospective ceremony is a time for team members to consider how to improve their way of working. This means they may change aspects of how they do Scrum, such as the length of their sprints. But a retrospective can also cover general aspects of working together, such as whether to ban morning meetings or which topics are appropriate to discuss on Slack and which require a face-to-face conversation.
The sprint retrospective should be attended by the whole team--that is, the development team, Scrum Master, and the product owner. To do otherwise is create a schism within the team. A good agile team should avoid any behavior that leads to an us/them mindset.
There are no formal inputs to a sprint retrospective other than a willingness to improve. The output is a list of changes the team will make to how it works.
The sprint retrospective is formally timeboxed to 3 hours. A retrospective may occasionally take that long but most teams will conduct most retrospectives within an hour.
Product backlog refinement refers to ensuring the items at the top of the product backlog are ready for the next sprint. This can include adding detail to existing items, estimating, deleting items, adjusting priorities, splitting product backlog items so as to better fit within a sprint, and creating new items.
While product backlog refinement itself is necessary, it is not mandatory that a team do refinement as a formal ceremony or that it be done every sprint. Most teams will, however, conduct regular product backlog refinement meetings, usually once per sprint or once per week.
Usual guidance is to spend no more than 10% of a team’s total available time on product backlog refinement both in meetings and in discussions that may result from those meetings.
Most teams will have the entire development team participate along with the product owner and Scrum Master. Unless a team will be estimating product backlog items during its refinement meetings, I find that perhaps half to two-thirds of the development is sufficient and reduces the overall meeting time burden on a team.
The only inputs to this ceremony are the items at the top of the product backlog. Outputs are product backlog items that are often split to be smaller and better fit within a sprint as well as greater understanding of some product backlog items.
As noted above, many teams will estimate during product backlog refinement meetings. That is the ideal approach, and is possible if the entire development team participates in backlog refinement.
If only a subset of the development participates in backlog refinement, team members will meet once per sprint to estimate any new work for which the product owner may need an estimate.
For most teams, these estimating ceremonies should be very short. Most teams should not generate or receive a flood of new product backlog items each sprint. Work to be estimated should either be important, new product backlog items or existing items that have been split to better fit in the coming sprint.
I like to do product backlog estimating immediately following a daily scrum, a couple of days before the end of the sprint. That is late enough that most new items will have been identified but in time for the product owner to adjust priorities based on the new information conveyed by the estimates.
I do not recommend estimating during sprint planning. That is too late for the product owner to adjust priorities based on the estimates. It also leads to team members spending longer than they should on estimating. So, don’t estimate product backlog items during sprint planning.
Before a new sprint begins, the product owner ensures the top of the product backlog has been prioritized. According the Oxford American Dictionary, prioritize means “to put tasks, problems, etc. in order of importance, so that you can deal with the most important first.”
This means it is not sufficient for a prioritization to merely say, “They’re all required.” Or, as one product owner told me, “They’re called requirements for a reason--they’re required.”
In most cases, there will not be an official prioritization ceremony. Rather, this is something the product owner does alone following conversations with stakeholders to understand their needs and desires.
Prioritization should happen as late as possible in the sprint, while making sure it’s done before the next sprint. This will often mean doing it on the last day or two of the sprint.
Usually prioritization is not time consuming. This is because the product owner is typically fine-tuning priorities based on progress and learning from the current sprint rather than performing an outright re-prioritization of an entire product backlog.
When does your team conduct these ceremonies? Are there other ceremonies you’d recommend other teams do? Are your participants the same as I’ve described? Please share your thoughts in the comments below.
Successful Scrum implementations involve a handful of important ceremonies. This includes sprint planning, the sprint review, the daily scrum, the sprint retrospective and more.
There’s often a lot of confusion about who participates, when these ceremonies are conducted, how long each can take, the purpose of the ceremony, and more.
To reduce the confusion, we’ve created infographics that answer each of these questions for sprints of 1-, 2-, 3- and 4-weeks.
The Sprint Planning Ceremony
Daily Scrum
What did I do yesterday to help achieve the sprint goal? What will I do today to achieve the sprint goal? What, if anything is impeding or blocking progress toward the sprint goal?
Sprint Review Ceremony
Sprint Retrospective Ceremony
Product Backlog Refinement
Backlog Estimating
Prioritization
When Do You Conduct These Ceremonies?
Posts
