>> Announcer: From Hell's Kitchen in New York City, it's theCUBE, on the ground at Serverlessconf. Brought to you by Silicon Angle Media. >> Hi, I'm Stu Miniman with theCUBE, here at Serverless Conference in Hell's Kitchen in New York City. Happy to welcome back to the program. keynote speaker at the event, and a guest that we've had on a couple times before, John Willis, who's the vice president of DevOps and digital practices at Eastray Technologies. John. >> In Hell's Kitchen. >> Stu: In Hell's Kitchen, and go Yankees. >> Yeah, man. I was at the game last night, the other night. Yeah. You'll see tonight. Yeah. Thank you. Glad to be here. >> Great to see you. So look, you've been talking to audiences about DevOps for as long as I can remember, as long as I've known you, definitely. Tell us, what's so important about serverless and how that fits into the world of the developer these days. >> Yeah, I mean, my interest, you know, I was invited to do a keynote, and my interest is to break down the tribal nature of new things. And I sound like a hypocrite because I'm the DevOps tribe, but I prefer to stop calling it DevOps, because there are super patterns that exist, and as I watch serverless, I spend a lot of time having these conversations around that yeah, we don't need that DevOps anymore, because we got serverless. It was the same reason like we didn't need any of the infrastructure stuff because we got cloud. And like, we keep throwing the baby out with the bathwater, and my presentation this morning was like, it's not about the technology, stupid. Like the principles of business value, how you understand value stream, how you inject the governance, the policy, the security, the values and the outcomes that you want. I know those sound like platitudes, like I get a sense that we're making the same mistake over again, and hey, sorry folks, Serverless is just another form of compute. Sorry to get you all wound up and then let you down. It's just compute, folks. And so all the core principles that we've really learned about high-performance organizations apply, they apply differently. Monitoring is differently. How do we deliver? But the principles stay the same. And that was my core message today. >> Yeah, no, very passionate, definitely came through in the keynote. I just have to ask you just on the tech for a second, I mean you were heavily involved in containers, you were part of a company that got acquired by Docker, you were a big proponent of unikernels, now it's serverless, how do you kind of paint that picture >> I think it's amazing tech, and more these days. So I left Docker and I'm going back to something I did 10 years ago, which is kind of consulting but transformation type consulting. It sounds platitudish, but like, I'm back in the mode of looking at things at bigger scale. How do you change an organization to think differently about things? So I've kind of taken a little bit of my tech hat off. I mean, I love containers and minimal delivery, right, I've been yacking about that for like the last two or three years, right? About how minimal delivery models work. And serverless is like, amazing too, like unikernels was an interesting model of function as a service. I think serverless will eat up a good portion, you know I've said this, and I don't know, I may have to modify it. You know, I would say four years ago, three years ago, and you guys been a big part of this discussion. The world went to most companies would say we're a cloud-first organization. I've been saying for the last couple of years, I think most organizations should now thinking that they're a container-first organization. So that doesn't say everything, it just means, and I think the world now should be kind of still container first, and I know that might sound horrible to serverless people, but then look at serverless functions as a place where it fits in the architecture, repeatability, and containers. And there's actually kind of a.. >> Is that just from a maturity standpoint, you know, containers a little bit more mature than serverless? >> I don't know that it's, I think there are like, there are models of architecture, right, and I don't know that, I mean I know there's a lot of successful startups in certain value streams and enterprises that are all serverless. I know a couple of friends that have built complete infrastructure on Amazon Lambda. It works. I just don't know that all value stream delivery of services will go complete serverless. I'm pretty certain that today, almost all applications can run on containers. So I'm not creating a division of war. I'm just saying that I think, and I could be dead wrong on this, but I think in this future like placeholder where we're container first, it's going to be, give me an exception of why it can't be containers left, like it has to be cloud, or it has to be bare metal, or it has to be (mumbles) and the right side is about mapping reusable functionality in functions. So I think you have like a container-first world assumes that smart architecture mandates repeatable functions in a function-like world. Does that make sense? >> Yeah, it does. So I think back on my career, there's so many times we said like, oh, we've got this new way to really simplify the environment and get rid of things you don't need to worry about. You know, I lived through the whole virtualization, oh wait, networking storage took us a decade to fix that. >> Yeah, yeah, yeah, yeah. >> Containers, oh we're going to just focus on the application. Oh wait, networking really important, you worked on a whole company focused specifically on that. >> DevOps for networking, yeah. >> Serverless, the question is, what's the rule of operations when it comes to serverless? >> Again, that's my thoughts on serverless and if it ain't right that's secondary to my real passion right now, which is when I hear the word NoOps for serverless, I cringe. Like this idea that you don't... I mean it's different. Do you need observability and telemetry in a serverless world? I ask you. Of course you do. Do you need to have repeatable patterns of delivery to make sure you don't have vulnerabilities in your code? Of course you do. That's Ops folks. And it's about supply chain and building repeatable, structured delivery with all the gates and the checks and the units, and none of that I believe goes away with serverless. Just like it didn't go away with cloud, just the way it didn't go with virtualization, right? So I think you know, we make a big mistake to think serverless means we don't need operations now. Does it mean that our providers, we have a different relationship with our providers? We don't own the server anymore. So we can't run detrace or those kind of things in that environment. But we still own the service. So who's the site reliability engineer for the service that's running on Lambda? Or functions of serverless, right? If it ain't, I mean if you don't got one, like you're going to have a bad service. >> Yeah, what are you hearing organizationally, what's happening in companies that you're talking to? You know, I was a at a show recently, I think it was Kelsey Hightower I think, it was like DevOps is a given at this point. So do you see that, you know, where's the line from what you've seen? >> Well the curse and the blessing of DevOps, the curse is we've never had a clear definition of it. I say we, you know, everybody, but. And the blessing is we've never had a clear definition. Like it's always emerged. And the problem is, I will tell you what my definition of DevOps is, it has really very little to do with technology. It has to do with human capital and how you create high-performing organizations and the principles and practices that lead to that. The DevOps handbook, if you will, is a lot about, that I co-authored with Gene and Patrick and Jez. Those things, that's my definition of DevOps, but the problem is, when you hear people have discussion about DevOps in lieu of a good definition, you can't really get upset when somebody thinks DevOps is like Jenkins and Sheffer Puppet and Ansable, and like oh no, you're wrong, right, like that's their view. So the problem that you run into then is, if your definition is that it's pure technology and it's tied to kind of cloud, and it's something like infrastructure is code, then in your world and your definition, serverless is going to make all that obsolete, or a good portion obsolete. But if your definition is more about how you create patterns and practices around humans who deliver services a certain way, then nothing about serverless makes any of that obsolete. >> All right, Jon, want to give you final word. What do you think people, that you know, just hearing about serverless first time, where do they start, what kind of things should they look at, or you know, if there's other things you think they should probably look at first? >> You know, I think you're asking the wrong guy for that really. I think there's far better people that you've interviewed take care of that. I mean I would go with Peters Brook, the founder of this conference. That was a book I read, he gave me a copy, it made sense to me, I was able to do some labs and then you know, as they say, the rest, Bob's your uncle, you know, there's a ton of stuff out there to figure out how to navigate. >> Anything, any commentary you'd make on the community for here, a couple of people just you know, it's new but very vibrant, reminds me a lot of the emerging tech where, you know, a lot of help from the community, it's pretty easy to get started. >> So yeah, so in the technology, yes. A lot of vendors, a lot of good stuff, great conversations, and I was actually pleasantly surprised there was less discussion about NoOps or you don't need operations, and I got kind of a little bit of a cheer when I mentioned that this morning. So it seems like there are some good lessons learned that I think the message loud and clear is that operations still exist, it just has to be thought about. The keynote yesterday, the gentleman in the keynote yesterday said, day one, closing keynote, said serverless things are different, in some case easier, but harder in other things, and that was through a cloud. Cloud was much easier from getting infrastructure but we ran into a whole lot of operational issues around how to match this cloud to scale. So serverless is easy to create a function, get it set up, cost-effective, but we're starting to learn all of the complex operational issues of MTTR, how do you restore stuff, what does SRE look like, I mean this is why we get paid the big bucks, dammit man. >> All right, John Willis, always a pleasure to catch up with you. I'm Stu Miniman, thank you so much for watching theCUBE.

>> Announcer: Live, from Washington DC, it's the CUBE. Covering .conf2017. Brought to you by Splunk. >> And welcome back here on theCUBE. John Walls and Dave Vellante, we're in Washington DC for .conf2017, Splunk's annual get together coming up to the nation's capital for the first time. This is the eighth year for the show, and 7,000 plus attendees, 65 countries, quite a wide menu of activities going on here. We'll get into that a little bit later on. We're joined now by a couple of gentlemen, Michael Arahuleta who is the Vice President of Engineering at Atlassian, Michael, thank you for being with us. >> Thank you, actually it's Director of Business Development. >> John: Oh, Director of Business Development, my apologies >> He's doin' a great job >> My apologies. >> I don't need that. >> Oh very good. And Brooke Gravitt, who I believe is the VP of Engineering, >> There ya go. >> And the Chief Software Architect at Forty8Fifty. >> Yep, how ya doin'? >> No promotions or job assignments, I've gotcha on the right path there? >> Yeah, yeah. >> Good deal, alright. Thank you for joining us, both of you. First off, let's just set the stage a little bit for the folks watching at home, tell us a little bit about your company, descriptions, core competencies, and your responsibilities, and then we'll get into the intersection, of why the two of you are here. So Michael, why don't you lead off. >> So Atlassian, we, in our simplest form, right, we make team collaboration software. So our goal as a company is to really help make the tools that companies use to collaborate and communicate internally. Our primary focus, and kind of our bread and butter has always been making the tools that software companies use to turn around and make their software. Which is a great position to be in, and an increasingly we're seeing ourselves expand into providing that team collaboration software products like Jira, Confluence, BitBucket, and now, the new introduction of a product called Stride, which is a real time team collaboration product, not just for technical teams, but we're really seeing a great opportunity to empower all teams 'cause every team in every organization needs a better way to communicate and get things done. That's really what Atlassian core focus is all about. >> John: Gotcha. Brooke, if you would. >> Yeah, so Forty8Fifty Labs, we're the software development and DevOps focused subsidiary of Veristor Systems based out of Atlanta. We focus primarily on four key partners, which would be Atlassian, Splunk, QA Symphony, and Red Hat, and primarily, we do integrations and extensibility around products that these guys provide as well as hosting, training, and consulting on DevOps and Atlassian products. >> So the ideal state in your worlds is you've got -- true DevOps, Agile, infrastructure as code, I'll throw all the buzzwords out at ya, but essentially you're not tossing code from the development team into the operations team who them hacks the code, messes it up, points fingers, all that stuff is in part anyway what you're about eliminating, >> Right. >> And getting to value sooner. Okay, so that's the sort of end state Nirvana. Many companies struggle with that obviously, You got, what, Gartner has this term, bimodal IT, which everybody, you know, everybody criticizes but it's sort of true. You've got hybrid clouds, you've got, you know, different skillsets, what is the state of, Agile development, DevOps, where are we in terms of organizational maturity? Wonder if you guys could comment. >> I'll start with that right, I think -- Even though we've been talking about DevOps for a while and companies like Atlassian and Splunk, we live and breathe it. I still think when you look at the vast majority of enterprises, we're still at the early stages of effectively implementing this. I think we're still really bringing the right definition to what DevOps is, we're kind of go through those cycles where either a buzzword gets hot, everybody glams onto it, but no one really knows what it means. I think we're really getting into that truly understanding what DevOps means. I know we've been working hard at Atlassian to really define that strong ecosystem of partners. We really see ourselves as kind of in the middle of that DevOps lifecycle, and we integrate with so many great solutions around monitoring and logging, testing, other operational softwares, and things of that nature to really complete that DevOps lifecycle. I think we're really just now finally seeing it come together and finally starting to see even larger organizations, very large Fortune 100 companies talk about how they know they've got to get away from Waterfall, they've got to embrace Agile, and they've got to get to a true DevOps culture, and I think that's where Atlassian is very strong, devs have loved us for a long time. Operations teams are really learning to embrace Atlassian as well. I think we're really going to great position to be at that mesh of what truly is DevOps as it really emerges in the next couple years. >> Brooke, people come to Forty8Fifty, and they say, alright, teach me how to fish in the DevOps world, is that right? >> Yeah, absolutely. I mean, one of the challenges that you have in large enterprises is bringing these two groups of people together, and one of the easy ways is to go out and buy a tool, I think the harder and more difficult challenge that they face is the culture change that's required to really have a successful DevOps transformation. So we do a little bit of consulting in that area with workshops with folks like Gene Kim, Gary Gruver, Jez Humble that we bring in who are sort of industry icons for that sort of DevOps transformation. To assist, based on our experiences ourselves in previous companies or engagements with customers where we've been successful. >> So the cloud native guys, people who are doing predominantly cloud, or smaller companies, tech companies presumably, have glommed onto this, what about the sort of the Fortune 1000, the Global 2000, what are we seeing in terms of their adoption, I mean, you mentioned Waterfall before, you talk to some application development heads will say, well listen, we got to protect some of our Waterfall, because it's appropriate. What are you seeing in the sort of traditional enterprise? >> We see the traditional enterprise really embracing Agile in a very aggressive way. Obviously they wouldn't be working with Atlassian if they weren't, so our view is probably a little bit tilted. Companies that engage with us are the more open to that. But we're definitely seeing that the far and away the vast majority in the reports that we get from our partners like Forty8Fifty Labs is that increasingly larger and larger companies are really aggressively looking to embrace Agile, bring these methodologies in, and the other simple truth is with the way Atlassian sells -- the way we sell our products online, we have always sort of grown kind of bottoms up inside a lot of these large organizations, so where officially IT may still be doing something else, they're always countless smaller teams within the organization that have embraced Atlassian, are using Atlassian products, and then, a year down the road, or two years down the road, we tend to then emerge as the defacto solution for the organization after we kind of spread through all these different groups within the company. It's a great growth strategy, a lot are trying to replicate it. >> Okay, what's the Splunk angle? What do you guys do with Splunk, and how does it affect your business? >> Mike: Do you want to start? >> Sure, so, we're both a partner of Splunk, a customer of Splunk, and we use it in our own products in terms of our hosting, and support methodologies that we leverage at Forty8Fifty. We use the product day in and day out, and so with Atlassian, we have pulled together a connector that is -- one half of it is a Splunk app, it's available on Splunk base, and the other part is in the Atlassian marketplace, which allows us to send events from Juris Service Desk, ticketing events, over to Splunk to be indexed. You have a data model that ties in and allows you to get some metrics out of those events, and then the return trip is to -- based on real time searches, or alerts, or things that you have -- you're very interested in reports, you can trigger issues to be created inside of Jira. >> I think the only thing to add to that, so definitely, that's been a great relationship and partnership, and we're seeing an increasing number of our partners also become partners with Splunk and vice versa, which is great. The other strong side to this as well, is our own internal use of Splunk. So, we as a company, we always like to empower our different teams to pick whatever solution they want to use, and embrace that, and really give that authority to the individual teams. However, with logging, we were having a huge problem where all of our different teams were using over a whole host variety of different logging solutions, and frankly not to go into all the details, it was a mess. Our security team decided to embrace Splunk and start using Splunk, and really got a lot of value out of the solution and fell in love with the solution. Which says a lot, because our security team doesn't normally like much of anything, especially if it's not homegrown. That was a huge statement there, and then quickly Splunk now has spread to our cloud team which is growing rapidly as our cloud scales dramatically. Our developers are using it for troubleshooting, our SREs and our support team for incident management, and it's even spread to our marketplace, which is one of the larger marketplaces out there today for third party apps. Then the new product, Stride, for team collaboration is going to be very dependent on Splunk for logging as well. It's become that uniform fabric. I even heard a dev use a term which I've never heard a dev talk about logs and talk about log love, which is no PR, that is the direct statement from a developer, which I thought was amazing to hear. 'cause you know, they just want to code and make stuff, they don't want to deal when it actually breaks and have to fix it. But with Splunk they've actually -- They're telling me they actually enjoy that. So that's a great -- >> That's more than the answer is in the logs, that's there's value in our logs, right? >> Yeah, a ton of value, right? Because at the end of the day, these alerts are coming in and then we use tools like the Forty8Fifty Labs tool to get those tickets into Jira. Those logs and things are coming in, that means there's an issue and there's something to be resolved and there's customer pain. So the quicker we can resolve that, that log is that first indicator of what's going on in the cloud and in our platforms to help us figure out how do we keep that customer happy? This isn't just work, and just a task, this is about delivering customer value and that log can be that first indicator. The sooner you can get something resolved, the sooner the customer's back to getting stuff done and that's really our focus as a company, right? How do we enable people to get things done? >> Excuse me, when you are talking about your customers, what are their pain points? Today? I mean, big data's getting bigger and more capabilities, you've got all kinds of transport problems and storage problems, and security problems, so what are the pain points for the people who are just trying to get up to speed, trying to get into the game, and that the kind of services you're trying to bring to them to open their eyes. >> I think if you look at the value stream mapping and time to market for most businesses, where Splunk and Atlassian play in is getting that fast feedback. The closer in to the development side, the left hand side of value stream that you can pull in, key metrics, and get an understanding of where issues are, that actually -- it's much less expensive to fix problems in development than when they're in production, obviously. Rolling things like Splunk that can be used as a SIM to do some security analysis on, whether it be product code or business process early, rather than end up with a data breach or finding something after it's already in production. That kind of stuff, those are the challenges that a lot of the companies are facing is -- especially when the news, if you look at all the things that are goin on from a security perspective, taking these two products and being able to detect things that are going on, trends, any sort of unusual activity, and immediately having that come back for somebody in a service desk to work on either as a security incident or if it's a developer finding a bug early in the lifecycle, and augmenting your sort of infrastructure as code, the build out of the infrastructure itself. Being able to log all that data, and look at the metrics around that to help you build more robust enterprise class platforms for your teams. >> We've been sort of joking earlier about how the big data, nobody really talks about big data anymore, interestingly, Splunk who used to never talk about big data is now talking about big data, cause they're kind of living it. It's almost like same wine, new bottle with machine learning and AI and deep learning are all kind of the new big data buzzwords, but my question is, as practitioners, you were describing a situation where you can sort of identify a problem, maybe get an alert, and then manually I guess remediate that problem, how far away are we from -- so the machines automating that remediation? Thoughts on that? >> Am I first up? >> You guys kind of -- >> We've done a lot of automated remdediation. Close with remediation is what you call it. The big challenge is, it's a multi-disciplinary effort, so you might have folks that need to have expertise between network and systems and the application stack, maybe load balancing. There's a lot of different pieces there, so step one is you got to have folks that have the capacity to actually create the automation for their domain of expertise, and then you need to have sort of that cross platform DevOps mindset of being able to pull that together and the coordinator role of let's orchastrate all of the automations, and then hopefully out of that, combined with machine learning, some of the stuff that you can do in AWS, or with IBM's got out. You can take some of that analysis and be a little bit smarter about running the automation. In terms of whether that's scaling things up, or when -- For example, if you're in a financial industry and you've got a webpage that people are doing bill pay for, if you have a single website down, a web server down, out of a farm of 1000, in a traditional NOC, that would be kind of red on a dashboard. It's high, it's low priority, but it's high visibility and it's just noise, and so leveraging machine learning, people do that in Splunk to really refine what actually shows up in the NOC, that's something I think is compelling to customers. >> How are devs dealing with complexity, obviously, collaboration tools help, but I mean, the level of complexity today, versus when you think back to client server, is orders of magnitude greater for admins and developers, now you got to throw in containers and microservices, and the amount of data, is the industry keeping pace with the pace of escalation of complexity, and if so, how? >> I think we're trying. I think that's where we come into play. As this complexity increases really the only way you can solve it is through better communication and better tools to make sure that teams have the right information at their fingertips. The other challenge too is now in the world of the cloud, these teams need to be on 24/7. But you've got to kind of roll across the globe, and have your support teams in different time zones. You don't always have the right people online at the same time to be able to address, and you can't always talk directly, so that's where having the right tools and processes in place are extremely important so that team can know and know what did the team earlier do, how did they resolve this, where's the run book for this issue, and if this happens, how do we resolve it? How do we do so quickly? I think that tooling is key, and also too, this complexity is also as you guys were talking about before, being solved through some automation as well, and we're increasingly seeing that to where if this occurs and a certain thing occurs, then Jira can now automatically start to trigger some things for you, and then report back as to what it did. You're going to see more and more of that going forward as these models become more intelligent and we can redeploy, or if capacity is low, let's pull back resources, and let's not spend all this money on cloud computing platforms that we may not need because utilization is low. You're seeing all of those things start to happen and Jira as that workflow engine is that engine that's making those things happen in either an automated way at times, or just enabling people to communicate and do things in a very logical fashion. >> As ecosystem partners, how do you view the evolution of Splunk, is it becoming a application platform for you? Are you concerned about swim lanes? I wonder if you could talk about that? >> I personally, I don't see any real concerns of overlap between Splunk and Atlassian. In our view at Atlassian is, we tend to work very closely with people kind of fit into that frenemy category, and they're definitely a partner that we overlap with I think in very very few ways. If and when we ever do, I mean in a way, that's kind of something we always embrace as a company. I mean one thing we'll say a lot is overlap is better than a gap. Because if there's a gap between us and a partner, then that's going to result in customer pain. That means there's nothing that's filling that void. I'd rather have some overlap, and then give the customer the power to choose how do they want to do it. I mean, Splunk says you can probably do it this way, Atlassian says you could do it this way, as long as they can get stuff done, and that's always -- it's not a cliche from us, I mean that's a core message from Atlassian, then we're happy. Regardless if they completely embrace it our way, a little bit, a little deviation, that's not what really matters. >> Too much better than too little. >> Exactly. >> Is what it comes down to. Gentlemen, thanks for being with us. >> Thank you. >> We appreciate the time today and look forward to seeing you down the road and looking as your relationship continues. Not only between the two companies, but with Splunk as well. Thanks for being here. >> Mike: Thank you guys. >> We continue theCUBE does, live from Washington DC here at .conf2017, back with more in just a bit.