Skip navigation

Monitoring Central

4 Posts authored by: gerardodada

There are many decisions in life where we come across the question of build or buy. A new house. A business. An application. Monitoring software. Regardless of the object of discussion, answering certain questions can act as gates for helping us along the path to the right solution—for us as individuals or as companies.

 

Take database monitoring software for example.

 

  • What are the requirements? What are the “must haves” vs. “nice to haves”?
  • Does a monitoring solution exist that at least meets minimum requirements?
  • Is there a competitive advantage to be realized by building?
  • What is the Total Cost of Ownership (TCO) of the build vs. buy options?

Requirements

 

Regarding requirements, be sure to get input from all of the stakeholders who will be involved or will benefit from the monitoring solution. This will include DBAs, developers, management, and application owners at a minimum, but may also extend to other IT disciplines (system admins, storage admins, VM admins, etc.). Be as thorough and detailed as possible when defining requirements. Be realistic on the “must haves” and try not to throw in the kitchen sink. Take into account best practices when defining requirements. There is a lot of good content out there on how to define requirements, so no need to be exhaustive here.

 

Does It Already Exist?

 

After requirements have been defined, the journey can begin. A quick Google® search will likely yield a number of alternatives for consideration. Some things to look for are:

  • Features that match requirements
  • Testimonials
  • Trusted reviews
  • Customer reviews
  • Satisfaction with the product and support
  • Specific strengths and weaknesses of the monitoring solution

In addition to the above research, evaluations are likely in order. All of the key boxes might get checked, but taking the candidate solutions for a test drive can go a long way in determining a good fit. This phase will likely involve talking with sales representatives from the vendors. This is a great opportunity to get additional information you may have missed during your research, or answers to questions that come up during evaluations. Restricting candidates for evaluation to three can save time and effort.

Competitive Advantage

 

Determining if there will be a competitive advantage by building monitoring software is a bit nebulous. Database monitoring tools in general are fairly mature for the major RDBMS vendors. Only databases without a significant install base are likely to not have any commercial off-the-shelf (COTS) monitoring solutions available. Still, if you don’t find a solution that meets your minimum criteria, you may be looking at a build scenario. In fact, many great startups resulted from needs that aren’t met by COTS products.

TCO

 

Purchasing perpetual COTS licenses is usually straightforward, in my experience. Costs to consider are the list price, the initial purchase/negotiated price (usually some percentage of list), and then maintenance (normally somewhere around 20% of list price due annually).

The TCO for building a solution is a bit more ambiguous. Costs to consider include development of the product, potential integration with other technologies, security, administration, opportunity cost (associated with not monitoring) while developing, and maintenance of the product when new versions/drivers are released on the target RDBMSs. Software development being what it is, a contingency factor of at least 20% should be built into the cost for rework, bug fixes, course adjustments, etc. And hey, if you do succeed in traveling the happy path during development, that’s cost reduction that can flow directly to the bottom line.

 

Conclusion

 

The decision to build vs. buy is a key one. It’s tempting to go down a path because it’s something that can be done. However, answering the questions listed here should help those making the decision to identify what should be done.

It seems DevOps is the new cool thing in IT. Sometimes it feels like DevOps is an amorphous thing that only cloud people can play with. For many of us who come from the client-server era, it can be intimidating.

 

We know DevOps can be defined in many ways. It can be thought of as a mindset, a methodology, or a set of tools. In this post, I offer a definition of DevOps by breaking the concept down into seven fundamental principles.

 

Implementing DevOps is very complex, requires new tools, new skills, and new processes. It’s often only possible for development and operation teams who are working together on cloud architecture software. I am excited about these seven principles because they can be applied in any IT organization.

 

Embracing these seven principles might enable your team to grow more agile, more responsive to business needs, and better able to meet expectations. The combination of these principles represents the mindset that companies are trying to hire for, and the mindset that is required to make the best use of cloud technologies, too.

 

These are the seven principles that define DevOps that you can integrate into your IT operations team:

 

  1. 1. Application and End-user Focus – Everyone on the team is focused on how their end-users and applications are impacted. The infrastructure is only there to make the application work.
  2. 2. Collaboration – Because the focus is on the end-user, silos do not work. If the app is down, everyone has failed. There are no virtualization problems or isolated storage issues. There is only one team: the one responsible for the app to work. This requires transparency, visibility, a consistent set of tools, and teamwork that supports applications across the entire technology stack.
  3. 3. Performance Orientation – Performance is a requirement and a core skill across the team. Performance is measured, all the time, everywhere. Bottlenecks and contentions are well understood. Performance is an SLA. It’s critical to the end-user experience. Everyone understands the direct relationship between performance, resource utilization, and cost.
  4. 4. Speed – Taking agile one step further, shorter, iterative processes allow teams to move faster, innovate, and serve the business more effectively.
  5. 5. Service orientation – No monolithic apps. Everything is a service, from application components to infrastructure. Everything is flexible and ready to scale or change.
  6. 6. Automation - To move faster, code, deployments, tests, monitoring, alerts; everything is automated. That includes IT services. Embrace self-service for your users and focus on what matters.
  7. 7. Monitor everything – Visibility is critical for speed and collaboration. Monitoring is a requirement and a discipline. Everything is tested, the impact of every change is known.

 

For more details, I invite you to read the full presentation:

The 7 Principles of DevOps and Cloud Applications

[slideshare id=56581871&doc=the7disciplinesofdevopsandcloudaplications2-151231191647]

The term “cloud” has stopped being useful as a description of a specific technology and business model. Everything, it seems, has some element of cloudiness. The definition of cloud versus on-premises has blurred.

 

It’s only been eight years since Gartner® defined the five attributes of cloud computing: scalable and elastic, service-based, shared, metered by use, uses internet technologies. Shortly after that, Forrester® defined the cloud as standard IT delivered via internet technologies on a pay per use, self-service model.

 

What we call on-premises is most often virtualized, dynamically provisioned infrastructure on a co-location hosting facility, programmable by software. Clouds now offer long-term, bare-metal, prepaid-for-the-year infrastructure, and private/dedicated infrastructure.

 

Organizations have learned that there is a place for cloud-hosted resources and a place for on-premises resources. The best analogy I have is this: there is a time when you want to buy a car and there is a time when you want to rent a car (or get a taxi). As Lew Moorman, president of Rackspace® told me many years ago, “the cloud is for everyone, but not for everything.”

 

It’s undeniable that every IT department is adopting the cloud, but it is also becoming increasingly clear that on-premises IT is not going away. Most companies will end up with a combination of the two. But how?

 

For the near future, there are mainly three broad ways to consume cloud by IT departments:

  • SaaS – From SalesForce® to Netsuite® and Office 365®
  • “Lift and Shift” – Where the architecture stays the same, and you only migrate the workloads to be hosted on a cloud
  • “Cloud first,” which takes full advantage of cloud architecture and services. This model is only viable for net new projects and for those where it makes sense to invest in writing or re-writing apps from the ground up.

 

The reason I bring this up is because when it comes to monitoring, application architecture is more important than where things are hosted.

 

A standard three-tier architecture application like SharePoint® on AWS® needs to be monitored essentially the same way it is monitored on-premises, or in a co-location environment. Conversely, a cloud-architected application (service-oriented, dynamically provisioned, horizontally scaled, etc.) will require a different monitoring approach, whether it is hosted on a public or a private cloud.

 

The key point is that cloud is quickly becoming irrelevant as a term. No one says they have an electronic calculator or a digital computer anymore.

 

We need to start using more specific terms that are more meaningful and useful, such as cloud services, cloud architecture, or cloud hosting – not just cloud.

SolarWinds THWACK® community has grown to become one of the largest and most active communities for IT professionals, expecting about two million unique visitors this year alone.

 

We see it as a great opportunity to have a conversation and to connect.

 

IT is changing all the time. That’s what makes it such an interesting industry. SolarWinds® solutions have been changing, too. In addition to our traditional product line, powered by the Orion® Platform, SolarWinds now offers a remote monitoring product line for MSPs, and a portfolio of cloud monitoring products for DevOps teams building cloud-first applications.

 

This makes it more important than ever that we have a space to connect with customers and with the IT industry. This is that space.

 

Monitoring Central complements our two other blog communities on THWACK: Geek Speak, where you can read opinions from industry thought leaders, and the Product Blog, where you find out about product updates and new releases.

 

Monitoring Central is a new space to talk about all things monitoring.

 

We invite you to participate, ask questions, voice your opinions, and actively participate in this blog. For example, write a comment below suggesting any topics you would like to hear about.

 

We look forward to the conversation.

SolarWinds uses cookies on its websites to make your online experience easier and better. By using our website, you consent to our use of cookies. For more information on cookies, see our cookie policy.