The Cloudcast #162 - Building and Managing Scalable SaaS Services

This episode of the cloudcast is sponsored by PagerDuty. Folks, if you work at ITOPS, IT administration, you've got to know PagerDuty. PagerDuty eliminates the noise, chaos, and manual processes across the entire incident life cycle. All the stuff that keeps you up at night, all the stuff that's complicated when applications fail and networks fail. And let's be honest, it happens. So PagerDuty is trusted by companies like Etsy, Nike, and GitHub. And a whole bunch of other companies that you guys know and trust on the internet. So to sign up for a free 30-day trial, visit www.pagerduty.com and now onto the show. Cloudcast Media presents from a massive studio in Rally, North Carolina. This is the cloudcast with Aaron Duff and Brian Brasley bringing you the best of cloud computing from around the world. Good morning, good evening, where we are and welcome to another episode of the cloudcast. We're coming to you live from our massive studios here in Rally, North Carolina. Unfortunately, Brian is a little under the weather tonight, so it's just myself. But we've got a great guest this evening. We've said for a while that we want to dig more into the ITOPS ecosystem and the breadth of services that really enable more robust web-scale applications, and tonight we're going to dig into that in two different ways, both how to build scalable SaaS services and to leverage very cool service that everyone really needs today. And with that, we've got Menage, Chaudhary, CTO, and VP of Engineering at Lugley. How are you doing, Menage? I'm doing great, thanks Aaron for inviting me on the show, I really appreciate you and cloudcast for inviting me. Thank you. Thank you very much. So, you actually, Menage, both you and your team came very highly recommended to us by the team over at EvidentIO. And we also learned about your service at the AWS Summit up in New York City. So tell us a little bit about your background and how it eventually led you to Lugley. Absolutely. I can do that. So let me first introduce myself and then give you a little brief about Lugley. I joined Lugley eight months ago, actually even before I talked Lugley and why I joined Lugley, let me talk about my prior experience and what I did in the past. I think that they'll give a little bit more background and color to the SaaS offering. We are building at Lugley and how we are building that robust nature of SaaS offering. So I joined Castiron system in 2003 as an engineer. I joined the company when there was not a whole lot of a product. Product was there, but it not functional, there's no customer. So from there, we built three different products at Castiron. It was Castiron was an integration company. It was trying to solve the integration needs of the customer. In those days, the integration products like Typco Webnitha's Vitria, they used to cost $1 million and then $2 to $3 million in professional services and then somewhere your two systems start talking to each other. So in Castiron, the first product we built was a physical appliance where we said you take this appliance, put it into your network and your integration needs will be solved. And as the virtualization technology start picking up in 2006, our customers start saying, you know what, it's very hard for us to bring this physical appliance. When you give us something which we can put on our virtual infrastructure because we have spent so much money. So what we did was we build a virtual appliance for the same product. And the cool thing about what we did there was a single code base offering which has same functionality, same feature, same price, but two different form factor. In 2008, the cloud wave got picked up and our customer said, you know what, now we don't even need your virtual appliance. We want something which we basically can connect from the cloud and our integration needs get solved. So we built first multi-attent and completely SaaS-based integration offering and we released that product in 2009. So in 2009, we offered three different form factor of same product, customer can choose whichever one they like. And in 2010, IBM came and acquired us and it was one of the very good acquisition of IBM WebSphere Group in 2010. At that time, I was running the whole engineering organization at Casta and System. And then what's really interesting about that kind of history is how that very much mirrored the industry in general going from physical to virtual to really more of as a service kind of offering. But what's interesting is you were actually able to successfully do all of those areas and kind of leap forward as the market was leaping forward when many companies really didn't. Yeah. I think and that's what is a testament to the Casta and team of basically keep evolving themselves as market growth. If we would have kept ourself as a physical appliance company, probably we would not have as good exit as we had in 2010 and IBM came and bought us, right? Sure. And I think key thing is to basically there, I learned and I was basically telling team when we were building our cloud-based offering and virtual appliance is, you know, the great companies basically build the product on a single core base have same features and have same price point for customer. And that's what we exactly did. Some of our customers said, you know what? For physical servers, the cost should be higher and for SaaS, it should be cheaper. And my answer to them was, you know, it is the value we provide to our customers is what is the price. You can take physical appliance if you think that's going to benefit. If you think virtual appliance, if you think SaaS, everything has the same feature. You pick and choose VCharge for a value, right? And that was huge for us. So that was fun times at Casta and then I stayed at IBM for two years, built two different product, apart from the original Casta and product, we built a Casta and Express, which was again a cloud-based multi-tenant offering. It was much lighter version of integration product, very, very easy to use. And then I built another product called API Management for Casta and it was based on the Casta and offering too. And when I had those two product build at IBM and was in production, I left IBM and joined GIF software in 2012. I joined GIF software to gain, I built two different products from scratch and was part of also doing an acquisition of a company and was basically evaluating and building the big data offering by the time I left the GIF, all of those products went live into production. And in the beginning of 2014, I joined Login and I'm really excited to be part of the team. This is an absolutely great time for a log management space. If you see every single person has started to realize that how important the log management has become, because more and more companies are becoming data-driven, more and more company are analyzing how their customers are using their product, more and more companies are making decision based on analysis of the data. And more and more companies are understanding that the first big data problem is the log management. So that's very fair because without a doubt, it just makes sense that logging is generating just a massive amount of data in an existing data center probably today. It may or may not be aggregated and it is very much at times a needle in a haystack trying to find the data you really needed at any given time. And sometimes you really need that data, it becomes really important data to be able to sift through and figure out what is going on. And you as a company and a SaaS provider who rely on the log management system, I'm not saying the on-premise companies don't rely. But I think the key focus for any companies is not try to build a log management infrastructure. should be focused on building the value to their product. and not worry about log management and literally use systems like log Lee to do analysis, alerting, debugging, figuring out what happens when the fire is happening on their production system they should use log Lee and that that's where the real value of log management is and what I have seen recently not only big players are getting attracted and start noticing the log management space but more and more small companies are realizing that log management they want to have in a centralized place rather than them trying to manage on their own because it's very expensive to build a log management solution with scales as your company grows as your customer base grows or as your number of server grows sure and that goes in with the common theme I hear a lot of times these days you know from just about any startup of you know more and more you hear about why would you own physical assets anymore and and whatever can be taken and hosted or managed somewhere else it is it makes sense because you're you're allowing yourself to focus on what really matters yeah and that actually leads into so you actually have a very excellent talk and presentation and we'll put a link to it in the show now it's on on critical SaaS mistakes to avoid and you mentioned that scalability needs to be priority number one how much different is building applications and services in the cloud versus say using you know package software yeah so I think you hit the nail on the head right that the difference between so if you look at the difference between the package software versus SaaS offering right is the reason any company come and use SaaS offering is they want to outsource the management the scalability aspect the recovery aspect the backup aspect and and basically don't want to worry about anything they basically sign up and assume that this service is going to be available 24 by 7 and I don't have to worry about anything whereas in package service in a package software you hand over a CD or a software to a customer and as a vendor your job is done you probably give them best practices on how to build an infrastructure which will scale which will basically have all the nitty gritty's so when things go haywire it can recover but guess who is managing the customer who bought from the vendor is taking owners of that problem whereas in SaaS customer is giving that owners to the vendor who's providing the service so in that that's why I say scalability and reliability for any multi tenant SaaS application is the P1 priority which each vendor of a SaaS application treat it as they should not treat it as oh scalability is a side effort which I will worry about later let me get my product out that is a huge mistake they should keep scalability as a P1 feature which with every single release every single feature development they keep in mind yeah and that's that's really interesting because you do hear sometimes people actually say of you know the whole the whole concept of minimal minimum viable product MVP of just get something out there and you can figure out all that other stuff later but but yeah when it comes to scalability really almost being that that most fundamental piece of if it's not right from the beginning you're pretty much rewriting your application anyway right and and and actually to talk about that for a little bit about you know the the whole concept of building web scale SaaS applications so I'm kind of making an assumption here but but I'm assuming logly was built from day one as a web scale SaaS application and kind of asking you you know lessons learned or or looking back is there anything that you would have either done differently or you you know like oh this this is something right here that was a decision we made that if we didn't make this decision things could have gone very bad okay yeah that is correct the logly was built as a SaaS product from day one and we will always be a SaaS company I at least in a near future I can see so I think it'll be valuable for me to just give a little bit more background on logly so logly was formed in September of 2009 founding team did a great job in coming up with the first version of the product and we call it a generation one product there was some scalability issue with that product and it was not really ready to go to the enterprise level so we decided in 2012 that we need to go and rebuild our product so that we are ready for next level of our customer enterprise class product very stable and have a feature set which the log management space is needed and the customer is aspiring for so we spent one year rewriting the product and what we did is when we when we were rewriting the product the goal set for the team was hey we need to write a product which able to consume as much as our as much as the customer through logs at us we should never drop the the log no matter at what rate customer sent to us right and then write a simple to use user interface we not gonna build the API first and then patch a user interface on top of it it is a consumer grade it's a product for enterprise that doesn't mean it need to suck we need to write a product which is for enterprise market with enterprise class feature with enterprise stability but a fee the usability aspect of it is a consumer grade simple to use low touch and people can come up to speed real quick and I'm so proud that we did exactly that right now what what lesson I have learned in SAS in general I would say is the key thing any company should be aware of is that what they expect their customer to behave customer will never behave or use the product the way they think or the way the SAS company think so solving the unpredictable pattern of usage of your product is key so for example we initially assume that when our customer will send the log data to us the traffic pattern will be pretty much consistent but what we realize is the pattern at which customer send traffic to us very humongous sometimes they're sending us at a normal rate of 2000 events per second suddenly they have an issue or a fire in the production and they start sending us at the rate of 200 thousand events per second or whatever I may be saying too much here but the pattern is not saying so we need to build an infrastructure when this kind of unpredictable load come from our customer we can shield well behaved customer and not penalize for that right that that's huge yeah and so that's that's interesting because if you think about it yeah this is potentially a very very complex system on the back end because you have to ingest you have to parse you have to analyze you have to tag data you have to multi-tenancy of isolating one customer from another customer managing historical logs over time and then exactly that visualize it build a an interface on top of all of this and potentially give recommendations all in in real time and so can you give us a sense of how that is set up behind the scenes and how all of that that magic kind of happens yes definitely I can and I can give you a flavor of it I I don't think it would be easy to give that information on and of course but it's as you just explained it's a very complex system right and One thing what customer expect in the log management system is the moment the log even leave their premises, they should be searchable from our UI right there and then. So they just don't want to see any latency in there. That's one. Two, they just don't, they can expect less feature less functionality, but they want reliability where their data will never get dropped right. So what we do behind the scene is we have built a massive infrastructure to make sure that nothing get dropped. What that mean is when this massive inflow of event come we can first first and foremost we can collect them at a network speed right our first entry point to log system is collector and they are the most efficient piece of software we have written so that no data get dropped the moment they grab the data they persisted and as you mentioned after that we basically have written a model where there are massive number of processes sitting which take from that persistent store where collector has put the data. Pull them in to in their in their memory and start processing them start massaging them and at every level when we do that massaging of the event or mapping it to a customer or parsing it according to the rule we keep persisting so that we don't lose that data and the real thing is even with that checkpoint the persistence after every business logic we have written a piece of software which is so efficient that we need our customer demand of leaving their log from their promises to be available to search in almost near real time. Gotcha and so based off of that what are the probably the most common scenarios that companies are deciding that hey I need help and a company such as logly can help me with this. Exactly so I think as I said right it's there are a lot of scenarios but what what I would say is we land up mostly in a green field situation where people have we people are not using any log management system right but what happens is log the log management is first big data problem if you see how many times when and a DevOps person get page at 3 a.m. in the morning with a pager call saying out of this space or running low in the desk the first reaction of them is let me go to the var log directory and see which are the logs I want to delete right so what they want to do is preserve that log they don't want to prematurely get rid of the log so when they need most those logs they don't have in their desk. Second thing they come to us for is to do analysis right when they when there after a production issue if they want to analyze what happened so that they can build that the tools to prevent similar kind of fires in the future they come and basically have used logly for they come to us to prevent those fires so they they basically configure alert for for a particular type of log which they can detect before a fire can hop happen so for example they say if I see 404 more than five times in less than a minute send my DevOps person a pager right a call so those are the kind of scenarios what customer come for one is before a fire they want to preserve their log go look at the issues in a normal study course of action when they have issue in the production they want to basically do a analysis of what happened in a production and take a corrective action and the third is to protect fires and detect in advance through the log that there is something going to happen wrong so they get notified before the fire happened. Cool very cool now talk about AWS for a second logging really became more visible at AWS Summit when AWS themselves announced centralized log management and and how does your world change when AWS elevates a service that that quite frankly plays in your domain it's funny you you ask that question right and I was I was mentioning in the beginning of this interview that we are seeing more traction towards log management market by this big players and to be honest I'm glad to see Amazon come in this place right it help us validate the market it help customer realize that this market is huge Amazon will come and enter into space which is which is basically not a million dollar market this is billions of dollars of market right and we think that they will be playing a partner role with us rather than a kind of a competition that's what high how I assume because their offering is more of an API where you can extract your logs from we are much more than that and so I really expect to play as a partner rather than a competition but it is good to have player like Amazon come into the log management space yeah and it really it really does seem like more and more AWS is choosing to really build out that any services they add really are more like foundational plumbing if you will and then you're building something on top of it that would potentially attach to that as opposed to them trying to build on full out applications and services they they definitely seem to be much more foundational at this time exactly and I say I see that more of what they expose their logins in some way that you might not want to do on Amazon alert at debugging on and that's how I see it because you're breaking up again but actually we're kind of out of time for this week so what I'll do is I'm just going to go ahead and close out the podcast on behalf of Minaj if you are interested go ahead and go to logly.com or on Twitter at logly and Minaj very much thank you thank you very much for your time this week if you like the show please tell a friend or leave us a review on iTunes you can follow us on Twitter at the cloudcast net are on the web at the cloudcast.net where you can find links to everything cloudcast thanks for listening thank you for listening we hope you enjoyed the show and by you of course we mean the NSA.