Sumo Logic ahead of the packRead article
Don't get punk'd in the cloud
Learn how to spot cloudwashing. Explore analyst reports, e-books, blog posts, videos and more.
Recycling is an important part of my family’s weekly chore patterns. Our Amazon deliveries alone generate copious amounts of cardboard for our weekly pickup in the giant blue can. I also find myself trying to think about the longevity of the stuff I buy and try not to be wasteful. I feel a sense of pride. But there is one area where I just don’t think recycling makes sense -- and that’s with software (that’s in addition to underwear and toothbrushes, of course…). How many times in your life have been frustrated because a software maker doesn’t seem to understand the system you’re using? Smartphone apps that don’t understand the concept of touchscreens, websites that seem to be designed for Windows desktop users in the 90s, much less for mobile. It is frustrating, right? As a long-term denizen of the world of computing and IT, I find it amusing we often drop these standards when dealing with enterprise software. Well, you shouldn’t have to.
Learn how to spot cloudwashing. Explore analyst reports, e-books, blog posts, videos and more.
The core truth is it’s hard for software vendors to change how they do things. It is hard for any vendor to retool their processes to build a new, better offering that will cannibalize their old business. It is no different with the data analytics market. Legacy tools were built to solve problems that are not top of mind now. Containers weren’t a thing in the last decade. Cloud computing wasn’t the standard in 2010 that it is today. Bottom line, as a team buying software, you should by no means feel guilty for refusing to be saddled with recycled analytics solutions.
You could argue we are only just now absorbing the massive changes wrought by the Internet over the last two decades. Cloud computing and microservices are the culmination of the work started in the late 90s and early 2000s. That doesn’t mean it is a simple transition from a server-based view from the mid-2000s to the fully microservices-based view of today. The default approach is to take the easy way out. Vendors just transition legacy solutions to the cloud (“lift and shift”), relabel it and then call it a day. But, let’s be clear -- that isn’t cloud. In particular, if the vendor is really just running their on-premise software on your behalf, you are essentially outsourcing the management of the product but gaining almost none of the benefits of the cloud.
You should set high expectations for a cloud product. It should aspire to align with the core principles of cloud-ness -- self-service, low cost of ownership, flexible, pay-for-what-you-use licensing, and near-instant scalability and elasticity through multi-tenancy. That’s what your customers are asking from you, so why wouldn’t you ask that of your cloud analytics vendor? So, let’s talk through a few of those aspects of core cloudiness.
One of the key changes of the last decade was that cubicle dwellers realized not all software and office products had to suck by definition. What we also come to expect is that I shouldn’t have to sit on a helpline to get a question answered. I should be able to access helpful docs, open support tickets, and make most adjustments myself. This is especially true for Cloud-native vendors. We run a subscription-based service and are up for reelection every year. We can’t afford to leave frustrated users alone and hope that things get better.
In the recycled software-as-outsourced-lift-and-shift model, only a few users are allowed to bother the vendor with pesky questions and support tickets, and for those who do -- time is definitely not of the essence. Since this is not a multi-tenant model, the configuration cannot be instantly changed. Single-tenant vendors need support tickets for basic changes like installing content, making administrative changes, or scratching the metaphorical nose of the software. The cloud-native vendor can’t afford this kind of antiquated approach to customer service. First of all, it is very expensive to not automate those administrative changes. Second, every unhappy user makes it more likely the cloud-native vendors lose their next election. You have to take care of your constituents.
The IT industry is constantly being reborn as technology advances. We went from mainframes to servers, from servers to virtualized services, from virtual machines to cloud, and now to containers and serverless. What always happens in those transitions is somebody’s licensing doesn’t fit the new model. In today’s microservices, vendors that were built around a server-based licensing system are wrapping their licensing models into pretzels of despair for their customers to handle containerization. “Why do you care how many containers I run per node?”. Well, they care because their whole licensing architecture is built around that core concept of a server because containers didn’t exist yet.
Conversely, let’s talk about data volume. In the olden days when a terabyte was still impressive, all data could be treated equally. Well, as terabytes have given way to more impressive petabytes and exabytes, the distinctions really matter. In the on-premise world, you could do some magic with your own storage. If you are using a recycled product in the cloud, you lose that control. You now realize you have no way to mitigate the one-size-fits-all approach that seemed harmless before. This is despite the fact that cloud platform providers like AWS provide all the flexibility that could be desired. You need the flexibility to match your costs to the value of your data - like paying much less to store audit data for a rainy day than your top-flight operational data.
Finally, life is a rollercoaster. In the real world, data patterns change dramatically over the course of a day, a week, a month, or a year. Particularly in today’s Internet-fueled economy, the difference between a Black Friday event and a normal day can be 10X or 100X. You don’t see Amazon, Google or Microsoft charging you in advance for the worst possible scenario? No. They charge based on what you use, seasonality makes no difference. Does nobody use your product during the weekend? You should pay less. Do you make most of your revenue in a couple of months of the year? You should pay less. This is like Oprah for data. “A car for you. A car for you. A car for you…”.
The bottom line is that licensing matters. Your cost structure determines what you can accomplish with your tools and what is out of reach. You shouldn’t be shackled to the outdated models of your tool vendors or be forced to accommodate yourself to their models.
It seems like this should go without saying, but shouldn’t we be past the days where teams of people are needed to manage the tools managing your application? You don’t need a team of 12 people to manage your Azure setup. Do you have 30 people managing your fancy new Google Apps account? I bet your DevOps-attuned people manage thousands of containers and virtual machines while still finding time to argue over the particulars of Python style over Slack.
So, why do we still have teams of people managing our analytics solutions? While it might be the height of awesome to some engineers to manage their unwieldy analytics steeds, does it make sense for the larger organization? (I would argue unless you are one of those tech companies being grilled by congressional panels that have so many MIT engineers to spare they have to let them blow off excess energy by constructing magnificent artifices of over-complicated infrastructure code in their 20% time, the answer to that question is no). I say bribe your engineers with free lunch and treadmill desks and leave the analytics platforming to those for whom it is their life’s work. The bottom line is that your engineers have better things to do than managing and running analytics tools.
One of the arguably more destructive myths today is that multi-tenancy is bad. So, let’s get this right. It’s totally cool for AWS to multi-tenant the heck out of your S3 and EC2 goodness, but then not the tools you use to monitor your application?! That’s crazy! The whole concept of the cloud is built on the concept that your cloud vendor of choice gives you flexibility, speed, and awesomeness on the strong back of multi-tenancy.
When you get enough customers on a single platform you can balance resource usage and gain efficiencies. The scale of the multi-tenant platform allows operators to build much smarter components. Think of the recycled single-tenant solution like a one-man band. There’s a big drum. Lederhosen, of course. Symbols. Maybe a trumpet. You know, Herr Trompetentoter von Schlagzeuger is really great for the local Oktoberfest or maybe your kid’s birthday party, but he is out of place at the Symphony Hall. He can’t scale to the occasion (see what I did there? Yep. You do.). You need an orchestra. And the orchestra can bring in the extra Tuba when needed or add an electric guitar for that collaboration with Metallica. The bottom line is that the orchestra is designed to be flexible and multi-faceted. Herr Trompetentoter von Schlagzeuger is very focused on a particular niche market.
It’s ok. Let’s wrap this up for you. The reason why thousands of customers have chosen Sumo Logic to be their analytics tool of choice is not because of our awesome name. It’s because we started out with a mission of using the power of the Cloud <cue soundtrack from the latest Avengers movie of choice> and turning towards making a product that solves the problems of the modern, hybrid enterprise -- not re-packaging warmed up leftovers from the night before. We believe the problems presented by the hyper-scale, speed, and utter chaos of the cloud-powered world can’t be solved using methods honed in the dark data centers of yore. So, you owe to yourself to keep the recycling to your local blue bin and try something new for analytics.
Build, run, and secure modern applications and cloud infrastructures.Start free trial