Recommended
Recommended
More Related Content
What's hot
What's hot (9)
Similar to What it Means to be a Next-Generation MSP - CloudHesive
Similar to What it Means to be a Next-Generation MSP - CloudHesive (20)
More from CloudHesive
More from CloudHesive (20)
Recently uploaded
Recently uploaded (20)
What it Means to be a Next-Generation MSP - CloudHesive
- 1. What it means to be a Next Generation MSP Presented by Patrick Hannah VP of Engineering, CloudHesive
- 2. • Who am I? • What is my background? • What do I hope to get out of this presentation? • How am I using AWS? • What do I love about AWS? Who am I?
- 3. Professional Services • Assessment (Current environment, datacenter or cloud footprint) • Strategy (Getting to the future state) • Migration (Environment-to-cloud, Datacenter-to-cloud) • Implementation (Point solutions) • Support (Break/fix and ongoing enhancement) DevOps Services • Assessment • Strategy • Implementation (Point solutions) • Management (Supporting infrastructure, solutions or ongoing enhancement) • Support (Break/fix and ongoing enhancement) Who is CloudHesive Managed Security Services (SecOps) • Encryption as a Service (EaaS) – encryption at rest and in flight • End Point Security as a Service • Threat Management • SOC II Type 2 Validated Next Generation Managed Services • Leveraging our Professional, DevOps and Managed Security Services • Single payer billing • Intelligent operations and automation • AWS Audited
- 4. Problem Statement: I need to be able to (monitor|get) information about my “things”. What’s important? What are my things? • Platforms • Environments • Systems • Servers • Services • Applications • Literal Things What characteristics of my things do I care about? • Is it up/down? • Have I crossed some sort of arbitrary threshold? • Is there an interesting event or lack thereof? • Is there a certain quantity of either?
- 5. Difference sources of data: • AWS, CloudWatch • AWS, CloudTrail • AWS, Config • Linux proc • Linux syslog • Windows WMI • Windows Event Log • Application Logs • Third party tool logs (APM, Security, etc.) How does that translate on AWS? Different methods of alerting: • E-Mail • SMS • Voice • Push Different methods of collecting: • Native APIs • Agents
- 6. • No trending • No single pane of glass • Redundant work • Lost data What’s the outcome of this approach?
- 7. Problem Statement: I need CONTEXT about the alerts I get from my “things”. What’s really important? Why? Things can carry different SLAs, depending on: • Type of environment • Where it sits in the lifecycle • What it does (mission critical, back office) • Type of customer (industry) • Does it heal itself? (autoscaling, recovery, etc.) • Context
- 8. DataDog is central to our event monitoring platform How does CloudHesive solve it? How does it work? • Data from the sources described on previous slides + more are sent to DataDog • It performs the initial triage via a series of pre-configured monitors • Non Severity 1 go to a work queue (Jira) • Severity 1 go to an escalation queue (OpsGenie) • All events persisted to long term storage (SumoLogic)
- 9. With outlier detection we are able to find underperforming members of clusters, autoscaled groups, etc and act appropriately. Outlier Detection!
- 10. We covered real time but what about looking backwards? • Root cause analysis (eg. on this date/time the application underperformed – why?) • Change planning (eg. expecting a 10x increase in traffic, will our autoscaling strategy work?) What else can we do?
- 11. Problem Statement: Now that I know what I want to monitor, how do I select the right tools? Integrations and the AWS Ecosystem Implemented by default • AWS Integration/Agent Installation/Agent Configuration Integrates • Over 100 integrations What does it do best? • Time series data, Key/Value pairs Scales (Operationally and Technically) • Ever run your own monitoring platform? The last thing you want is your platform to be impacted by the same event impacting your monitored infrastructure
- 12. • Insight across customers • New customers get a default suite of integrations and monitors • Support customer DevOps initiatives • Stronger Next Generation MSP • Security? Security! What powers do we gain?
Editor's Notes
- Who are you? Patrick Hannah, CloudHesive (where I’m a co-founder and the VP of Engineering) What’s your background? Architecture, Security, DevOps on AWS for 6 years, prior to that Contact Center Architecture and Operations for over 8 years. What do you hope to get out of the presentation? I want to help folks get as the same out of AWS as I have. I’d also like to see how others are using AWS – as with just about any thing in technology there are multiple ways to do something right (or wrong). How are you using cloud services? Every aspect of my life From Alexa powered Echos to my day job. Why did you pick the cloud services that you are using? AWS is at the forefront of Cloud; their service catalog can support most traditional on-premise software use cases (infrastructure) but they also offer more abstracted services for software built on the cloud that negate the need to manage server infrastructure – on premise or on cloud.
- CloudHesive offers end-to-end solutions to migrate and securely operate our customers’ mission critical applications on the Public Cloud. We were founded in 2014 with the purpose of enabling our customers’ use of the Public Cloud, specifically AWS. Our offerings span four distinct categories: Professional Services, DevOps, Managed Security Services and Next Generation Managed Services.
- What’s important? That’s a somewhat vague question. In this case, I’m referring to monitoring. Something for which you will get varying answer from depending on who you ask. To me, monitoring solves the general challenge faced by developers, operations, business, etc. around the need for visibility into the full stack of their infrastructure. This spans a number of different components and can be performed in a number of different ways, and is often encountered with strong opinion.
- The visibility provided by AWS into the infrastructure and the instrumentation provided by development platform specific libraries exponentially grows the data points generated by and associated with the application. Coupled with the various streams of alerting (noise), you may find your team spending more time managing alerts than doing their jobs.
- Traditional approaches to monitoring fail to address the challenge of correlating data across multiple services. You lose the ability to trend and you need to review multiple systems to come to a conclusion, resulting in redundant work and the loss of important monitoring data.
- So monitoring is important, but what’s really important? More than getting data thrown at you, you need context to understand the importance of that data and action to take. Outage of a development environment during non-development hours is not a Sev1 Crossing a CPU threshold in an auto scaled environment may not be important. Am I looking at data from a real time perspective? Or Historical?
- DataDog is the tool used to collect initial events from our various systems. CloudHesive has been using DataDog for over two years to collect, sort through, process and categorize the data received from these systems and make decisions on what action to take. Coupled with a rich set of integrations (like the ones listed on this slide + more) it is an excellent platform for Next Generation MSPs to leverage to solve their need to corral the ever growing sets of operational data. More challenges exist to solve, specifically around dealing with fixed thresholds, fixed counts and alerting based on pattern (or lack of pattern) matching. So what else can we do?
- Leveraging the outlier detection capabilities in DataDog, we have the ability to look at how pools of resources are behaving and identify underperforming (or simply not working resources). In the past, this has provided us insight into poorly performing hardware (think first generation instances, overprovisioned instances and bare metal issues (neither on AWS). It’s also helped us identify application issues around garbage collection, configuration, etc.
- The focus of the presentation to this point has been about the real time collection, processing and alerting of data in DataDog. Just as important, though, we need to be able to look back to identify events that may have been overlooked, perform root cause analysis or perform capacity planning.
- As mentioned before, monitoring tools have been around for some time now and the AWS Ecosystem is filled with them. How do I pick the right one for my use case? When we selected DataDog, we reviewed about 8 monitoring platforms, from open source to commercial to SaaS. We ultimately decided it is not our core business to run a monitoring platform (for which I did in a previous life and still have nightmares about). My initial philosophy on monitoring was agentless, but after running into numerous SNMP bugs, warmed up to the idea (pre DataDog). With that said, we narrowed down the list and ultimately selected DataDog for it’s ease of implementation (pretty much there by default) and it’s strong suite of integrations. DataDog recently introduced an APM and is capable of handling events (such as Windows Event Log), which makes it seem like a single tool to do all jobs. In our case, we went with a strategy where DataDog was the prime collector, processor and forwarder for threshold based events (time series data, etc.) and went through similar processes finding Log management, APM and Escalation platforms. We were pleasantly surprised to see how well these integrated, specifically New Relic, SumoLogic, OpsGenie and Slack. Even better, if an integration didn’t’ exist, we wrote it. As a matter of fact DataDog is the key engine in some of the autoscaling solutions we have implemented and we have gone so far as to recommend it’s use in IoT devices.
- To conclude my presentation, in the final slide I will talk about the powers we gained from implementing DataDog. We have unparalleled insight across our customers. This let’s us identify platform wide outages as well as make recommendations to customers on which configurations work best for their particular use case. New customers get the collective insight we have by way of a default suite of integrations and monitors. It also allows us to support our customer’s DevOps initiatives in a number of ways, but cannot stress how well it works with AutoScaling. All-in-all it makes us a stronger Next Generation MSP, and we continue to improve our operations with it, and visa versa. Last but not least, while we focused on operational monitoring, DataDog is not only designed with security in mind, but helps support our managed security services as well. Operational metrics are good early indicators of Security Breaches, and we have successfully identified issues in the past based on them (not to mention security tools can pass their data into DataDog and likewise).