>> Live from San Francisco, it's theCUBE covering DockerCon 18, brought to you by Docker and its ecosystem partners. >> Welcome back to theCUBE's coverage of DockerCon 2018. We are in San Francisco at Moscone, US. It's a spectacular day in San Francisco. It's a day to play hooky frankly, or play hooky and watch theCUBE. I'm Lisa Martin with John Troyer, and we're excited to welcome to theCUBE Abby Fuller, Developer Relations from AWS. Abby, great to have you here. >> Happy to be here. >> So you were a speaker at DockerCon 2018. Tell us a little bit about that and your role in Developer Relations. >> So I work in Developer Relations for AWS. So I used to be a devops engineer, and now I go around talking to customers and developers and other software engineers, and teaching them how to use things with AWS, or this morning it was teaching everyone how to build effective Docker images. >> So I read in your bio on the DockerCon website of the speakers that you're a container fan. We know you're a music fan, but you're also a container fan. What is it about that technology that you just go, "Oh, this is awesome, "and I can't wait to teach people "about the benefits of this"? >> So I switched over to container as a customer before I started working at AWS, and the biggest reasons for me, the first one was portability, so that I could do everything that I needed to run my application all in one place. So I think a big problem for a lot of developers is the whole what works on my machine? So being able to package everything together so that it worked on my machine, but also on a staging environment, a QA environment, and on your machine, that was the biggest thing for me. And that it removed some of the spaghetti code that came before, and it just made everything, it was all packaged nicely, I could deploy it a little bit more easily, a little bit faster, and I eliminated a lot of the why doesn't it work now when it worked before? >> Abby, one of the paradoxes of where we are in 2018 is AWS has been around for a decade, but yet here at the show, about half the folks raised their hand to the question, this is your first DockerCon? Are you just getting started with Docker and containers? So as an evangelist, Evangelist Developer Relations, you're the front line of talking with people at the grassroots. So can you talk a little bit about some of the different personas you encounter? Are you meeting people who are just getting started with their container journey? Or are you spending a lot of time kind of finessing the details about that API, APIs and changes and things like that at AWS? >> I think my favorite part about talking to AWS customers is that you get the whole range, right? So you get people that are just starting and they wanna know how do I build a container? How do I run it? How do I start from zero? And then you get the people that have been doing it for maybe a year or maybe two years, and they're looking for like advanced black belt tips, and then you get the other group which is not everyone is building a greenfield application, so then you get a really interesting subset where they're trying to move over from the whole monolith to micro services story. So they're trying to containerize and kind of adopt agile containerize approaches as they're moving over, and I think the best part is being able to talk to the whole range 'cause then it's never boring. >> What are some of the big barriers that you see for organizations that are maybe on the very very beginning of the journey or maybe before it, when you're talking with customers or developers, what are some of the things that you're hearing them say, "Ah, but what about these? "How can you help me eliminate these challenges?" >> Two big ones for me. The first one is the organizational changes that go around the infrastructure change. So it doesn't always work to just containerize what you already had, and then call it a day. So a lot of people are decomposing, they're going with micro services at the same time as they're going with containers. And I think wrapping your head around that kind of decomposition is the first kind of big challenge. And I think that we really just had to educate better. So show people, so here are some ways that you can break your service up, here are some things to think about when you're figuring out service boundaries. And I think the other one is that they often want a little bit of help when they're getting started. So either educational resources or how can AWS manage part of their infrastructure? Will they focus on the container part? So it's really interesting and it runs a whole gamut. >> Abby, you in Developer Relations, I love the trend, the community orient and trend, they're great, of peers helping peers, you're out there, you're wearing a Bruce Springsteen shirt right now, you made a Wu Tang joke in your talk today which is something that one did not do a few years back, right? You had to kinda dress up, and you were usually a man, and you wore a tie. >> Got my blazer on today. >> You look very sharp. Don't get me wrong. But as you talk to people, one, what's your day like or week like? How many miles do you have this year? That's private. But also as people come up to you, what do they ask you? Are you a role model for folks? Do people come up and say, "How can I do this too?" >> Yeah, so miles for this year. I think like 175,000. >> Already just in June? >> Already this year. So, this is a lot of what I do. I talk to all kinds of customers. I do bigger events like this, I do meet-ups, I do user groups, I go to AWS summits, and dev days and builders days, and things like that. I meet with customers. So day-to-day changes everyday. I'm obviously big on Twitter, spend a lot of time tweeting on planes. It really depends. This is a lot of what I do and I think people, I don't think you can ever really call yourself a role model, right? I love showing people that there's pass into tech that didn't start off with a computer science degree, that there's tons of ways to participate and be part of the tech community, 'cause it's a great community. >> You're not just a talker, you're a coder too. >> Yeah, yeah, so every job before this one with the exception of my very first job which was in sales. I was a dev ops engineer right up until I took the job at AWS, and I like to think that I never left, I'm just no longer on call. But I build my own demos, I write my own blog posts, I do all my own slides and workshops, so still super active, just not on call, so it's the best of all the worlds. >> So you went to Tufts, you didn't major in computer science. >> No. >> You are, I would say, a role model. You might not consider yourself one-- >> Well you can say it, yeah. >> I can say it exactly. It's PC if I say it. But, one of the things that's exciting to have females on the show, and I geek out on this is, we don't have a lot of females in tech. I mean, I think the last stat that I saw recently was less than 25% of technical roles are held by women. What was your career path if we can kinda pivot on that for a second, 'cause I think that's quite interesting. And what are some of the things that you've said, "You know what, I don't care. "I enjoy this, I wanna do this,"? 'Cause in all circumstances you are a role model, but I'd love to understand some of the things you encountered, and maybe some of your advice to those that'll be following in your footsteps. >> Yeah, so I went to school for politics. Programming was a little bit of a side hobby before that, mostly of the how can I do this thing, do this thing that it's not supposed to be doing? So I did that, I went to school. I took a computer science class my very last semester in school. I did not know that it was a thing before then, so I'm I guess a little slow in the comp sci uptake. And I was like, oh wow cool, this is an awesome, this could be an awesome career, but I don't know how to get into it. So I was like okay, I'm gonna go to a startup, and I'm gonna do whatever. So I take a sales job. I did that for maybe nine or 10 months. And I started taking on side projects. So how to write email templates in HTML that I could use that directly showed an impact to my sales job. Then the startup, as startups do, got acquired. And as part of the acquisition I moved my little CRM engineering job to the product team. And then, I'm gonna be honest, I bothered the CTO a lot. And I learned side projects. I was like I've learned Python now, what can you have for me? So I basically bothered him a lot until he helped me do some projects, and totally old enough now to admit that he was very kind to take a chance on me. And then I worked hard. I did a lot of online classes. I read a lot of books. I read a lot of blogs. I'm a big proponent in learning by doing. So I still learn things the same way. I read about it, I decide that I wanna use it, I try it out, and then at the point where I get where I don't quite know what's happening, I go back to documentation. And that got me through a couple of devops jobs until I got to evangelism. And I think the biggest advice I have for people is it's okay to not know what you want right away which is how I have a politics degree. But you can work at it. And don't be afraid to have mentors and communities and peers that can help you 'cause it's the best way to participate, and it's actually whether you have a comp sci job or not, it's still the best way to participate, and that you can have, there are so many nontraditional paths to tech, and I think everyone is equally valuable, because I think I write better coming from a liberal arts degree than I would have otherwise. So I think every skill that you bring in is valuable. So once you figure out what you want, don't be afraid to ask for it. >> The thing I'm hearing here is persistence. And it just reminded me, a quick pivot, of I hosted theCUBE at Women Transforming Technology just a couple weeks ago at VMWare, and they just made a massive investment, 15 million into a lab, a research lab at Stanford, to look at the barriers that women in tech are facing. And one of our guests, Pratima Rao Gluckman, just wrote a book called Nevertheless, She Persisted. It reminded me of you because that's one of the things that I'm hearing from you is that persistence that I think is a really unique thing there. Sorry, I just had to take a little side. >> I saw you looked that up. And actually I saw the title and I have not read it yet, but I have a flight back to New York after this so I'll have to find that. >> You've got time. >> Yeah. >> Over and over again as I talk with folks about IT and tech careers, right? It's that thinking expansively about your job, trying things, being a continuous learner, that is the thing that actually works. Maybe pivoting back to the tech for a sec then, obviously here container central, DockerCon 2018, Kubernetes actually was a big news this morning at the keynote, a big announcement, how Docker EE is gonna connect to Amazon EKS among others, kind of being able to manage the Kubernetes clusters up there in the cloud. And EKS actually just had, it just had its general availability I believe, right? In the last week or so? >> Yeah, so, excited to see EKS in the keynote this morning. We're always happy to deepen our partnerships. Yeah, and we've been in preview since re:Invent, and then we announced the general though of EKS, so Amazon Elastic Container Service for Kubernetes, long acronym. So EKS, we announced the GA last Tuesday. >> The interesting thing about AWS is somebody just compared it, I saw a tweet today to an industrial supply store and it's a huge warehouse full of tools that you can use, and that includes containers. But for containers, the three pieces that are the largest are EKS, ECS, and Fargate. Can you kinda tease those out for us really briefly? >> Yeah so envision if you would a flow chart. So if you wanna run a managed container on AWS, first you pick your orchestration tool, so EKS or ECS. ECS is the one that we've been working on for quite a few years now, so Elastic Container Service. Once you've chosen your orchestration tool, for ECS you have another set of choices which is either to run your containers in the EC2 mode which is manager, cluster, infrastructure as well, so the underlying EC2 hosts. And Fargate mode, where you only manage everything at the container level and task definition level, so no cluster management. >> And that's all taken care of for you. >> That's all taken care of for you. So Fargate I think is not actually a service in the traditional way that we would say that ECS is a service, and more of like an underlying technology, so that's what enables you to manage everything at just the container level and not at the cluster level. But I think the best way of describing it is actually is, there's a really nice quote floating around that said, "When I ask someone for a sandwich, "they don't wanna know the whole sandwich logistics chain, "so how do I get turkey, how do I get cheese, "how do I get mayo on the bread, "they just want the sandwich." So Fargate for, I think, a lot of people, is the sandwich. So I just want the sandwich, just give me your container, don't worry about the rest. >> So we've already established Abby has a lot of miles already in half a year, so I'm thinking two things. One, we should travel with her 'cause we're probably gonna get free upgrades. And two, you speak with a lot of customers. So tell us about that customer feedback loop. >> Something that I really love about working at Amazon is that so much of our roadmap is driven by customer feedback. So actually something that was really cool is that this morning, so ECS announced a daemon-scheduler, so run tasks one per host on every host in the cluster, so for things like metrics, containers, and log containers. And something that is so cool for me is that I asked for that as a customer, and I just watched us announced it this morning. It's incredible to see every single time that the feedback loop is closed, that people ask for it and then we build it. The same thing with EKS, right? We want you to have a great experience running your infrastructure on AWS, full stop. >> Can you give us an example of a customer that's really been impactful in terms of that feedback loop? One that really sticks out to you as a great hallmark of what you guys are enabling. >> I think that all of our customers are impactful in the feedback loop, right? Anyone from a really small startup to a really large enterprise. I think one that was really exciting to me was a very small Israeli startup. They went all in on managing no EC2 instances very quickly. They're called The Tree. So they were my customer speaker at the Tel Aviv summit, and they managed zero EC2 instances. So they have Fargate, they have Lambda, they managed no infrastructure themselves. And I just think it's so cool to watch people want things, and then adopt them so quickly. And the response on Twitter after the daemon-scheduler this morning is like, my favorite tweet was, "This is customer feedback done right." And I love seeing how happy people are when they ask for something or are saying, "Now that you've added that, "I can delete three Lambda functions "because you made it easy." And I love seeing feedback like that. So I think everyone is impactful, but that one stuck out to me as someone that adopted something incredibly quickly and have been so, they're just so happy to have a need solved for them. >> Well that's the best validation that you can get is through the voice of the customer. So to hear that must feel good that not only are we listening, but we're doing things right in a way that our customers are feeling how valuable they are to us. >> Happy customers are the best customers. >> They definitely are. >> Yeah. >> We learn a lot from the ones that aren't happy, and there's a lot of learnings there, but hearing that validation is icing on the cake. >> Always. >> Last question for you. With some of the announcements that came out today, and as this conference and its figure has grown tremendously, when I was walking out of the general session this morning, I took a photo because I don't think I've seen a general session room that big in a long time, and that was just at the Sapphire last week which has 20,000 attendees. I was impressed with how captivated the audience was. So last question, what excites you about some of the things that Docker announced today? >> So I think that's interesting. Something that's excited me in general is watching the community itself flourished. So there's many, there's Kubernetes CGroups, and there's user groups, the discussion online is always incredibly rich and vibrant, and there are so many people that are just so excited for anything. It's all companies building what they're looking for. And I love seeing things like the Docker Enterprise Edition announcement this morning where the demo is EKS, but I just love seeing customers get the choice to do whatever they want. They have all the options out there, and that you can see how much more rich and vibrant everything is. From even a couple years ago, there's more people every year, there's more sessions every year, the sessions are bigger every year. And I just love that. And I love seeing when people get so excited, and then seeing people that came to your talk two years ago, come back and give their own talk I think is amazing. >> Oh, talk about feedback. That must have felt really good. >> I think it's not a reflection on me, it's a reflection on the community. And it's a very supportive community, and it's a very excited and curious audience. So if you see their reception to other people that talk a lot being like, oh we're really happy to have you, then the next year you're like, well I have a story and I wanna tell it, so I'm gonna sit in my own session, and I think that's the best. >> Well Abby, it's been such a pleasure to have you on theCUBE, thank you. >> Thank you for having me. >> Thank you for stopping by. And your energy is infectious so you'll have to come back. >> Anytime. >> We wanna thank you for watching theCUBE. I'm Lisa Martin with John Troyer, live from San Francisco at DockerCon 2018. Stick around, we'll be right back after a short break. (upbeat music)

>> Announcer: From Boston, Massachusetts, it's theCUBE, covering Red Hat Summit 2017 brought to you by Red Hat. (electronic music) >> Welcome back to the Red Hat Summit here in Boston, Massachusetts, I'm Rebecca Knight, your host, my cohost, Stu Miniman, we are joined by Tim Cramer, he is the engineering director at Ansible Red Hat. Thanks so much for joining us, Tim. >> Hey, great to be here. >> So, you've been at Ansible a couple of years now, talk a little bit about your role, what you do, and new projects you're working on. >> All right, yeah, so I came over with the acquisition of Ansible into Red Hat, I manage the Ansible engineering team and I now have the Insights engineering team as well. We have many cool projects that we've been working on, one that's really exciting was Networking, but I know that you've talked to other people about that one. Another one is Ansible Container, which I'm also really excited about. What we've done is we noticed the Dockerfile sure did look convoluted, so we thought, it kind of looked like a bad shell script, and we thought well since we take bad shell scripts and we turn them into playbooks, into something very human readable, wouldn't it be great if we did the same thing for Dockerfile? So that's what Ansible Container really is. It's for companies that have really invested in Ansible, and they have a lot of Ansible content, take that content and be able to basically onboard it into OpenShift really easily with the Ansible container project. >> I actually, it was interesting, we were talking about kind of the history and things like the old Solaris Containers versus Docker, I read an interesting article talking about you know, containers aren't a thing it's more like a collection of things because I mean, you've got Linux Namespaces, Cgroups, and all those pieces, so it sounds like that's one of things that you guys are trying to help like Red Hat has always done, bring some supervision to some of these open source pieces. >> Yeah, a big thing about Ansible the thing that we try to do, over and over again is just make things as simple as possible, we're all about simplicity, and that's what we're trying to do on the Docker, sort of lifecycle. Between Dockerfile becoming easier, we also try to make it easier for you to be able to compose those into some kind of running set of microservices. >> Tim, since you came over with the acquisition, one thing that we've noted is, you know, Ansible's everywhere this week, it's been 18 months since the acquisition, we talked to Joe Fitzgerald, we talked to Andreas and it's getting it's pieces all over the place and sounds like more, could you give us a little bit of the insider view as to, you know, how that progression went, you know, what you're seeing, any challenges, I mean, we know it's all open source, but what do you have to navigate and how do you get that one plus one equals three once you put all this stuff together? >> Yeah, so I think that the acquisition itself was a really great move, right? It was great for Ansible, it was great for Red Hat. It filled a gap that they needed on the automation side and to make their products easier to install, configure especially, so what we noticed is that right after the acquisition Red Hat really just tried to let us keep going and run the business as is. They didn't try to force us into any specific model that they had for running things at Red Hat. What naturally happened was, because of the acquisition a lot of teams just started using it, playing with it, we were there as a consulting team to help a bunch of teams through whatever questions they had, but it took off virally just like it seems to take off virally with a lot of our customers. It is in literally every product that Red Hat ships today and then we have deeper integrations with some of the products. I know you've talked probably about CloudForms and Ansible Inside and we have a better integration with Satellite and Insights is the other one that's really good. >> In terms of the acquisition, what about the cultures? Before the cameras were rolling we were talking about how deep the Red Hat culture runs, really that's sort of brought down by Jim Whitehurst. Ansible had its own culture, how has the blending of the cultures been from your perspective? >> Yeah, one thing that I was really excited about coming in was, I've been in several large enterprises and I've been acquired now, this will be the third time that I've been acquired, and it's definitely the best one. This is a software company and that in itself is very exciting, because we're not trying to placate the hardware teams or you know, with some software add on stuff that I had in other acquisitions. The culture at Red Hat is one of really cooperation and everybody helping each other out, working together in communities, especially upstream communities, it's really upstream community first oriented, and that really helps teams integrate better at Red Hat because we can just work in our upstream community, we work in other people's upstream communities and get everything to tie together, it's a really nice collaborative model. So that culture of collaboration, and everybody's trying to get things done, do the right thing, it's fascinating. >> In a previous interview, you described your management philosophy as one of trust and enablement and that is something we've heard a lot at this conference is really empowering the individual, trusting the individual, it sounds wonderful, and it's the kind of boss I would want to work for, but how do you do it, what are some of the practices that you do to ensure that your engineers feel supported? And that you trust them? >> Well first, we do have a few job openings, so if you want to apply. >> (laughs) Okay, good to know. >> I guess some of the practices that I have when it comes to trust and enablement is I give my, there's an unending amount of work to do, right? So it's actually kind of an easy philosophy to employ. I just make sure that my team has a set of directives that are really clear, that they need to perform and you do sort of trust but verify, right? So you give them a bunch of actions to perform and make sure that you're checking in regularly and let them solve problems the way they want to. If they have an issue, or a question, or they're confused about something, we just cover it in a one on one or in a group meeting. The other thing that I do a lot of is, I tend to do a lot of group meetings. So I have my entire staff, like an all hands event, we do those every two weeks to make sure everybody's on the same page about what's going on in the greater Red Hat and within our own projects and I think that keeps people really tied in. >> Tim, management is something that gets pulled out, you know, pulled out from every vendor in the environment. The cloud guys are trying to build more into it, those infrastructure guys you mentioned that do hardware are all, you know, trying to do that pieces. Talk to us a little bit about your customers, why they turn to Red Hat and Ansible rather than to some of the other alternatives that are out there. >> Sure, so again, I think that one of the things that's given us a huge advantage is that Ansible is just so simple and we appeal to a very broad range of users. So I think that's why it took off so quickly and is used by so many people. So a system that anybody that can write a shell script can start using Ansible and writing playbook and we've got tons of examples out there so you can cargo cult things. So it's number one, really, really easy to get going. I just lost my train of thought, and the question was? >> Customers, why they're choosing it. >> Oh, customers, yeah. On the customer side, I'll give you an example. So there's a large technology company in Silicon Valley that uses us, and I can't say their name, but one of the problems that they had was utilizing, well, they were having problems communicating between development and production, okay? So the development guys would go off and they'd come up with a product and they'd know how they would deploy it in development, but when it came to production they needed you know, a different way of deploying it. So they used to create these giant documents, requirements documents and they'd pass them back and forth and they would speak different languages, it really wouldn't work, it'd take a long time to get something into prod. Now they're using Ansible Playbooks as that definition. Since it's so readable, the production guys can understand what they're trying to do, the development guys can easily write that in. So it's a great communication mechanism between those teams, it really helps create a real DevOps environment for them. So that's one good example. >> Look at management, it usually has a different pricing structure than some of the rest of Red Hat, some of the cloud models, how do you guys look at pricing? How are you trying to make sure that you make it as you know, affordable as possible for customers? >> Wow, yeah, that's not my area (laughs). >> Fair enough, you want to talk a little bit about some other customers, you know, you're here at the show, what are they asking you about, what are they excited about, I'd love to get some of the customer viewpoints that you're hearing this week. >> It's been fascinating, I've done mostly customer interviews the whole time and what I get is a lot of positivity. They're excited about Ansible, they're excited about the integrations that we're having with the other Red Hat products, it's taking off everywhere and yeah, they're generally just really happy with the product. We have a lot of interest in Tower as well which helps manage your Ansible environment. It's been super positive. >> As you look forward, what do we expect to see going forward? We understand Ansible will keep growing across the portfolios and environments, but what excites you and what should we look for going forward? >> So I think within the community one thing that I'm excited about is the number of contributors we have, right? We have over 2,600 contributors to Ansible and even like in our Windows practice, we've got 83 people that are working actively on helping our Windows modules. I want to see that continue to accelerate, I want to be able to make sure that our contributors are able to get changes in quickly and easily and that's something that we've been focusing on a lot. One thing about a really large community, it's great because you get a lot of attention, but the difficult part is that you can't accept all the contributions that people want to give you without just letting anything in, so we've come up with some techniques now, we have some bots that we wrote that help people formulate their pull requests and what I see going forward is we'll get more and more contributions in. >> And you'll continue that, creating more bots to let more people in, or let more people contribute? >> Yeah, we're also doing some tagging, so we're making it really clear what things are really managed by the core team itself, right? All the basic stuff and the engine of Ansible, then we have vendor modules, that's another thing that's pretty exciting, a lot of vendors are coming in and contributing publicly which is fantastic, especially on the networking side. And then we'll have those things that are curated so they have an active maintainer within the community, and they go through review from our core team to make sure that they're up to the right standards, but those are modules you know you can count on and then we'll have more of that wild west, you know, experimental modules. >> Rebecca: I like it. >> People are really trying some things out. That's one way that we can really help, if we can get a lot more of those wild west and let those settle a little bit, get some community leadership and kind of take off, and then they go into the curated pile. >> Rebecca: It's the open source way. >> Tim: It is. >> Tim, thanks so much for joining us. >> Right, yeah, it's great being here. >> I'm Rebecca Knight for Stu Miniman, we will continue with more of Red Hat in Boston, Massachusetts after this. (electronic music)