You may not be ready for a full-time resource yet, or you may be sensitive to the cost of recruiting and retaining a person with such a specialized skill set. When managing a growing business, database administration will inevitably become critical to delivering for your customers. They keep your data secure, available and scalable. This is a specialized skill set that often can’t be absorbed by your DevOps Engineer, System Administrator or Developers.
A full-time DBA is a big commitment – they are difficult to recruit and often cost the business well over $100,000. It’s natural to start your database management journey with a contractor or worse, stick with an accidental DBA. There are some details to consider when thinking about bringing on a contractor. Below are 5 tips to get more from your contractors.
If you’re looking to hire a DBA contractor or outsource your database management, you’ll need to consider availability. If your data needs to be available around the clock, you’ll need someone on-call for emergencies. Be wary of DBA moonlighters who simply can’t give your mission-critical systems the attention you need during unscheduled downtime, and state all SLA tiers clearly in your contract. There is nothing worse than having an emergency with no one to put out the fire. If you don’t have enough work to keep a full-time DBA busy, but you have mission-critical databases that need monitoring, consider a Managed Services Provider that can monitor those systems 24/7.
If you do hire a single contractor, you’ll have to pay a higher hourly rate on nights and weekends. Be prepared with a back-up plan and escalation processes in-case you can’t reach your contractor. If you have a project-based need, set clear goals and expectations for the deliverables. The skills a contractor needs to complete more complex problems can vary widely, so ask frank and probing questions about his/her experience with similar projects.
When it comes to hiring multiple remote workers, managing the team is key. Your team is only as healthy as how well it communicates together, and it can become strained in a remote situation due to the lack of proximity. Consider equipping your management team with the tools they need to foster great communication and consistent team building.
Loop your contractors into your IT meetings (yes, you’ll have to eat the per-hour cost of them attending but it’s worth it), and consider holding video calls rather than just voice to bring visual connection across locations. Creating an atmosphere like this will facilitate strategic buy-in and accountability from your remote contractors as they get to know other members of the team.
Hiring DBA contractors can be immensely helpful when it comes to tight deadlines and periods of explosive growth for your business. Whether you have unexpected project work or a gap in your technical capabilities, the extra help is key to reducing overall team stress and burnout. Consider these three things to help the transition go well.
Hiring an SME is a great way to avoid pitfalls when your team takes on a new project. the Data Platform has become a vast industry of technical expertise. During your digital transformation, you may need everything from cloud architecture to disaster recovery and back up.
SMEs specialize in one area of the data platform and should have helped organizations similar to yours complete the major projects you’re facing. That experience keeps you on track and brings peace of mind to the process. Trade the anxiety of hiring a generalist for the peace of mind a subject matter expert provides. SMEs can be difficult to find. Managed service and professional services companies typically have multiple skill-sets on-demand if time and scope are an issue.
Hiring a solo independent contractor can be great for short-term and smaller projects. If you want to save time and lessen your “management burden,” you may also want to consider hiring a company that offers multiple and comprehensive services such as:
Need more help in outsourcing your database management, contact at 844-282-DATA (3282)
Outsourcing your database management can be an efficient, money-saving option for a growing business. However, it’s important to weigh the risks of engaging a contractor with the cost of hiring a full-time employee. If you need to better increase your data’s availability, expand your system’s scalability, all while building your team’s capabilities, consider Fortified Data’s Core Health
Original post by Colleen M. Morrow found here.
This post is part of a series on this blog that will explore SQL Server Service Broker, a native messaging and queuing technology built into the SQL Server Database Engine.
See all posts in the series here.
In this installment, we introduce the basic Service Broker service architecture components.
Before I jump into the technical details of the Service Broker architecture, I think it helps to have a real-world analogy of what Service Broker is and does. In the last installment, I used the example of ordering something from Amazon.com. This time, I’d like to use an analogy that’s somewhat timely: taxes.
Each year, we fill out that 1040 or 1040EZ form and we send it to the Internal Revenue Service. Maybe we eFile, maybe we mail it in, it doesn’t matter. That form is received by the IRS and goes into a queue, awaiting review. At some point, days, maybe weeks later, our tax return is processed. If all goes well, our return is approved and the IRS cuts us a check. That is a Service Broker application.
The first Service Broker components we define in a new application are the message types. The message type defines name and format of messages that will be exchanged between services. When we create a message type, we have the option of also applying validation, basically saying the message must adhere to a specific format. That validation format may be well-formed XML, XML of a specific schema, an empty message, or we can say no validation at all, in which case the message content could be anything. In our tax example we had 2 message types: the tax return form we submit and the check we get back. Each of these has a well-defined format with specific fields it must contain.
CREATE MESSAGE TYPE [//SBDemo/Taxes/TaxFormMessage] VALIDATION = WELL_FORMED_XML; CREATE MESSAGE TYPE [//SBDemo/Taxes/TreasuryCheckMessage] VALIDATION = WELL_FORMED_XML; CREATE MESSAGE TYPE [//SBDemo/Taxes/AuditNotificationMessage] VALIDATION = WELL_FORMED_XML; GO
Once the message types have been defined, the next component we need to create is the contract. A Service Broker contract specifies which message types allowed in a conversation and which participant can send which message type. In our tax example, the taxpayer sends the 1040 message type and the IRS sends the treasury check. The IRS, however, would never send the taxpayer a completed 1040 form and a taxpayer would never send a treasury check. Why is this important? By defining what message types can be sent by each participant in a Service Broker app, we’re helping the receiving participant identify when an unauthorized message is received, thereby making our Service Broker app more secure.
Note that a contract can specify more than one message type for any participant. For example, the IRS can also send an audit notice. And the taxpayer can also send other forms or, unfortunately, a personal check. The same holds true for a Service Broker contract.
CREATE CONTRACT [//SBDemo/Taxes/TaxContract] ( [//SBDemo/Taxes/TaxFormMessage] SENT BY INITIATOR, [//SBDemo/Taxes/TreasuryCheckMessage] SENT BY TARGET, [//SBDemo/Taxes/AuditNotificationMessage] SENT BY TARGET ); GO
So, message types and contracts are pretty straightforward, right? The next 2 components sometimes cause a little confusion. Let’s start with queues.
A Service Broker queue is, at its essence, a hidden table in SQL Server that stores messages until they’re processed. Each message in the queue is a row in that hidden table. But the cool thing about this hidden table is that it’s not totally hidden. You can SELECT from it, but you can’t perform any DML operations on it. Like any other “real” table in the database, the queue is included in transactions, logging, database backups, database mirroring, etc., just like a “real” table. Each participant in a Service Broker application needs to have a queue to store received messages. In our tax analogy, I like to picture the queue as a cheap plastic inbox sitting on some sad desk in the IRS offices (complete with dreary florescent lighting, ala “Joe Versus the Volcano”). Our 1040 form will stay in that inbox until Tom Hanks processes it.
CREATE QUEUE TaxpayerQueue; CREATE QUEUE IRSQueue;
A Service Broker service is an addressable endpoint for conversations that bundles up a specific contract and queue. Huh? When we send our tax return form in, we don’t send it to a specific inbox on a desk, right? We send it to the Internal Revenue Service. And sending our return information to the Internal Revenue Service implies the adherence to the contract that was laid out earlier (we send in a specific form, they send us a check, etc.). And when we send that form to the IRS, the form automatically gets placed in that inbox (queue). Similarly, in a Service Broker application, we don’t send a message to a queue, we send it to a service. By sending a message to a specific service, we agree to use the message types defined in the contract on that service and SQL Server automatically places our message into the queue associated with that service.
CREATE SERVICE [//SBDemo/Taxes/TaxpayerService] ON QUEUE TaxpayerQueue ([//SBDemo/Taxes/TaxContract]); GO
CREATE SERVICE [//SBDemo/Taxes/IRSService] ON QUEUE IRSQueue ([//SBDemo/Taxes/TaxContract]); GO
That is a very basic introduction into the Service Broker architecture. Once we’ve created our message types, contract, queues, and services, we’re ready to start sending and receiving messages. More on that next time
Congratulations. Your team is ready for a DBA. You may not be ready for a full-time resource yet, or you may be sensitive to the cost of recruiting and retaining a person with such a specialized skill set. When managing a growing business, database administration will inevitably become critical to delivering for your customers. They […]
Read Story
Oracle and Microsoft announced a huge cloud partnership this month, and it’s a really exciting evolution for enterprises who are in both SQL Server and Oracle environments. For now, it looks like the cross-cloud capabilities only supports the Azure US East or Oracle’s Ashburn data center, but the potential is a big relief to those […]
Read Story
When embracing the change that accompanies any platform modernization project, it’s important to have a workable plan and execution strategy for cloud migrations.
Read Story
Learn our thoughts surrounding the technical and business lessons of this story, but more importantly, how your company can avoid this kind of press.
Read Story
Growing up, my dad would often encourage me to focus on the small and simple things in life. It was his hope that, with this knowledge, I would accomplish great things. By playing, working, and socializing, the small things we learn create patterns of behavior. We are creatures of habit and the more we repeat […]
Read Story
Read more about my own conversion to the DevOps model here. You hear the word “DevOps” thrown around quite a lot. It has become a buzzword which is unfortunate because the term holds significant meaning. The level of potential reduced risk coupled with developer and administrator empowerment is astounding. When a DevOps methodology has been […]
Read Story
Personal changes and mental shifts aren’t the only changes that need to happen in order to convert to an IT DevOps Model. There are serious business adjustments that need to be made as part of this process. Admittedly, this process starts out overwhelming (the change curve is real), but you will get there, I promise. […]
Read Story
We are excited to make Inc.’s 5000 most inspiring companies for 2018 with 405% growth over the last three years. To us this showcases how our model of results-driven managed services can result in real success. Fortified Data’s team approaches managed services as a partnership, pairing a strong methodology with a commitment to transparent reporting. […]
Read Story
There are 2 types of security in Service Broker: dialog and transport. Dialog security establishes a secure, authenticated connection between Service Broker Services or dialog endpoints.
Read Story
Service Broker uses TCP/IP to communicate with other Service Broker services on the network.
Read Story