Avoid the Ninja Anti-Pattern, Planning Out Your Cloud Platform Project (Ep. 48)

Episode 35 · 52:32 · SRT · archive.org · all Tanzu Talk

well hello everybody it's another Pivotal Conversations podcast you know i've been i've been traveling to san francisco the week for the annual team kickoff meeting i know i know that richard had his annual team kickoff meeting i think the uh the uh the week before that so we did this this thing have you ever done one of these richard we as a team building exercise nominally we went to a uh a cooking school thing where like you cook i gotta be honest i was kind of like you know what i would rather do go to a restaurant but i think uh i think it turned out all right i like it i'm glad we went there i learned i learned a few skills i think the problem with stuff like this with me is that like when confronted by an expert i i don't like to uh be a student for as much as i talk about like needing to learn to change and all of that like uh that's not for me i'm too old for that but i think uh i think it turned out well i got some tips on knives on cooking chicken and we made uh we made a curry from scratch it's delicious you ever do one of those i have done one of those as a uh date night before with my with my lovely wife so that's those things are are fun i uh you know our team building we went bowling and anytime i can stick my fingers into other people's uh weird bowling balls and get hepatitis or something you gotta you gotta take it man i wasn't sure where you're gonna go with that little speech there turned out well i had to quickly repivot that that was important to uh end in the right place how about how about your well first why don't you just briefly introduce yourself guest hi i'm john feminella uh i'm a pivotal employee like michael and richard and i work in the platform architecture group and mostly what that means is that i get to help customers with really difficult problems um specifically in enterprises figure out what those really hard problems are and how maybe pivotal can help them solve it now speaking of hard problems have you ever been to one of these cooking classes i actually have not been to a cooking class before but i tried to keep up on my culinary education by watching a lot of

gordon ramsay youtube videos oh sure screaming at people which i feel like i'm learning by osmosis through some extent there but so you have a lot of opinions on cooking like steak and drapes yeah exactly i used to love that show the first time it came out hell's kitchen that was fun i don't it's like the only reality tv show i ever watched well i'm a little ashamed to admit this but actually the favorite my favorite gordon ramsay videos are two kinds so there's one where uh there's something they call master class uh junior or i'm sorry master chef junior where he is running effectively a game show with these um but these people would otherwise be chefs that's regular master chef but master chef junior is the same thing with like basically elementary and middle school kids that are like 9 10 11 years old and what's amazing is he doesn't yell at them because he knows that like he has totally different expectations about the kids and he's like really loving and supportive and then you see exactly the same show and exactly the same format but with people who have been like cooking for 10 or 15 years and he's just like furious with them when they don't make a souffle correctly i mean there's a non-zero percent of the population that kind of wishes he screamed at the kids right that's just me all right that's right now i've been i've been thinking in these you know to to to to pivot around from a bad conversation again like in the in these in these weird times of ours there's not enough podcasts that are sort of like the uh that cover the full spectrum of opinion and that would be a good name for it a uh non non-zero percentage or whatever it's sort of like it's it's that's that would be a funny name for the there are some people who believe this and you could hear hear what they they think so speaking of things that uh people believe there's really no segue off of that but uh i think i think there were some actual accounting

facts put out this week now i haven't looked at all of the uh the earning summary i've seen the the sort of headline stuff for it but we had uh we had do we have to say alphabet can we just say google i feel like yeah i hate saying opposite i feel like that's some sort of like brainwashing that i don't want to participate but whatever so so the google holding company ghc uh c came out with their numbers i didn't really i saw one headline that there was some hidden like a multi-hundred dollar thing and some research thing that as the headline said and wall street is fine with it but that's good like i think uh they potentially if i looked at these kind of things would be an interesting company because of the way they hold the company their stuff out and looks like microsoft came out vmware i don't know what's what's your overall take on uh earning season so far richard yeah google did well which was nice microsoft had like a 90 increase in azure stuff which seems like a good percentage when you're already probably measuring in the billions so you know cloud stuff not shockingly continues to grow alphabet slash google's doing well i thought the vmware one i included was interesting since they have kind of righted the ship a little bit on software that it's kind of hit a good steady place in nsx their networking stack is on pace to be an x billion dollar business for them so they're doing a good job on software revenues and i think diversifying in a nice way i think their ceo even said this was one of their more more balanced quarters in a while so either way it's just it's cool to see when the old guard can continue to reinvent themselves and not necessarily just kind of flail around well let me let me let me let me ask this of uh of our guest here so when you're when you're uh you know out and about there farting around with the the large organizations doing stuff like how much how much like vmware stuff do you see yeah i mean it really depends on the client right because everybody's got a different mix of different things but it's certainly an established name and it's certainly um you know certainly a name people have heard of as opposed to say alphabet uh it's a relatively new brand and people are still being like well that's really google right nobody wants to call it alphabet yet uh but if you say vmware people are definitely understand what that means understand the product portfolio especially if

you're one of my customers which are you know large banks large financial institutions they've been running vmware of some form or another somewhere in their house for at least five to ten years yeah yeah you know i mean to uh the channel one of my uh one of my old which is say someone i've known not that they're aged one of my old uh dell buddies matt baker who works on strategy he was he was always very fond of pointing out that uh virtualization was indeed a thing and i think you know one of the one of the sort of like market tracking disappointments i've i've had uh when i was one as well but i've had with the analyst community is they don't i i would expect there would be this framing of like uh you know i mean vmware obviously sort of our buddies so like i don't want to like uh put them down or anything at all but you know there's this notion of like it's great to be in the buggy whip business except for that last year where all the revenue drops out right so there's there's this theory that virtualization and on-premise let me broaden it to private cloud that on-premise is on that but like you know it's kind of like the uh it's similar to like next year vdi is going to be really big right um which are the headlines you always see at the beginning of any year and so like i it would be nice if like some industry analysts out there had some sort of tracker that was like you know the the buggy whip curve because like so far like it hasn't happened at all as far as i can tell um and uh no one seems to track it and like you know we talk with analysts a lot and um one of the first hurdles you get over uh with let's say a run-of-the-mill analyst is basically like well obviously private cloud is stupid so we don't need to talk about that and you're like uh so you know it is it is it would be nice if the analyst community track that better so that's my homework assignment for this episode there you go i mean they did that announcement back in the fall with amazon and vmware and so i mean i think the vmware is trying to be smart and say when they don't want to just get

surprised by some cliff at some point in the future if it even comes so let's make it really easy to be vmware on aws and potentially keep milking that for a long time until the next big thing is figured out by by some of these traditional software companies yeah i mean i mean it's like so to hopefully and i say this to myself to close out the topic like i think i think in from the years of 2008 to 2009 uh horace deju he did this very effectively with pcs and mobile like he had a lot of great charts that were like very actively showing the uh the the market share replacement of pcs over mobile and uh i've never really seen a similar thing uh tracked over time year over year for uh public and private cloud which which uh which makes me suspicious of you always i mean speaking of the earnings that you mentioned i i remember three years ago i believe it was where an analyst had said that windows phone was going to overtake android by i think this year or next year and you know speaking of that earnings were off like 80 percent for microsoft phone in this earnings report so i mean that's a dead product at this point so you just wonder sometimes people get burned and don't want to make uh actually put a stake in the ground on claims like that that's right so so in in in other cloud news on the on the uh the side of the buggy whip cliff that where it's all about spark plugs the uh google there's updated their stack driver stuff that to have something that richard has been waiting all week to say what is that thing yeah i mean if you can say nozzle and friendly conversation really you've got to take it and that's uh so google stack driver nozzle for pcf it's in beta and our the team up here in seattle actually helped work on that our team worked with google folks and what that means is that you can kind of pump out some of the metrics in pcf into the stack driver platform in google and do some additional analytics and so forth so it's a good platform it does you know cross cloud it's aws ngcp the way stack driver works so it's just great to have yet another nozzle out of pcf and there's ones for splunk and there's ones for other products but it's good to have the stack driver one end stack

driver updated they have audit logging now so for all those enterprisey shops who like to have actual audit trails for who changes firewall rules and who did things on the platform this actually captures the logs about who did what in gcp and so they keep evolving that platform probably as they continue to want to be more enterprise friendly that's a really nice feature that just came out yeah i haven't looked at stack drive in a long time but back when i was uh uh i guess that when i was at 451 when i when i ran the infrastructure software practice which has like monitoring and systems management i remember they uh they seem very comprehensive and like legit so yeah it was it was uh it's good for google that they acquired them and i guess and i guess i guess by virtue of this fact and that you've interacted with them it's it's a product that they're still uh growing and investing in and uh and and relying on which which is good to hear for the for the uh the alphabet folks yeah i know i curled up by the fire reading stack driver documentation last night so it was it was earlier last night yeah yeah yeah that's almost like you know my my wife bought me a uh an electric blanket throw blanket because because i i get cold and i have to imagine that that reading systems management documentation is is a bit like that except maybe it has that feel of like remember when hair dryers you could look in and there was like that that heating element that would come on and you were like this is basically a toaster that i'm holding to my head that blows i don't know i think maybe it might feel a little remember when as in like they don't exist anymore or i guess so i don't know i haven't really like looked down the barrel of a hairdryer in a long time so maybe they still do i would i would think instead of metal they would use ceramic or something like i feel like i feel like that would be a good what is this 21st century hairdryer innovation i see i'm still stuck on you with the electric blanket given we're the same age and it makes you sound like you're 90 so i'm trying to recognize this man when when i can finally get to that low pan state or i'm basically in a wheelchair the whole time with a plaid blanket over me just telling people i can't hear them that's that's that's uh

that's that's my court my annual goals how can i accelerate that process picote right there that's right i just want to low pan into the sunset that'd be great uh and and then uh i think i think finally something something that uh also kind of in the systems management space it looks like it looks like app dynamics uh was this last week i forget or the beginning of this week it was announced they were about to ipo they had an s1 filed and everything which i haven't gotten to look at so sad i used to go look at all this stuff uh but now i get to talk with delightful people like y'all but uh yeah it looks like they decided instead to to be acquired to cisco i read a few little uh i i wouldn't call them heart racing no uh no heating element in a hairdryer kind of stuff but some fun accounts of kind of uh how it must have happened where you're on the road show and meanwhile you're uh you're one of your your rogue i bankers is out there and sells to cisco but if i remember the numbers they sold for like three point around five billion uh and uh and they were gonna the idea was they're gonna ipo at 1.9 billion so uh at least the investors got got a much better multiple i guess and then they're part of the uh the cisco world which as as i'm as i'm i don't know if fond is the right word but as i find myself pointing out people are often like cisco has software and yes indeed they do like several several uh many years ago they bought a uh a runbook automation company called either objects is in there or manage i forget maybe both of them and they've acquired some uh some uh systems management kind of stuff over the year now i think i think i assume the conceit with app dynamics i remember when i used to work on strategy not that this would ever happen but this kind of thing would come up a lot it's like well as things go cloud the nature of systems management changes so if we want to leapfrog our software nascent software portfolio we should consider these new types of apm tools and stuff which uh seems to fit nicely there yeah yeah i mean they're definitely uh i mean cisco's doing a lot of interesting things with acquisition i think we're we're all waiting to

see how it all comes together but you know the biggest takeaway is that if you're in the pivotal ecosystem your chances of being acquired at a high multiple are great so for all you partners who aren't yet with pivotal get on that not that uh not to extrapolate too much from the correlation isn't causation but sure like you know one one you're always one good i banker away from an amazing uh amazing deal with cisco or your favorite company yeah yeah and then i i think richard must be right if you were to look at the pitch deck that the it's it's i keep wanting to say like uh like quade like in uh that it's catalyst misspelled with a q so i keep wanting to say quatilist you know open your mind to a higher valuation and going private but uh i'm sure in their pitch deck there's a big slide that has a pcf logo on it richard that uh that must have been in there well you know come on we got name dropped in the google earnings report yesterday by the google ceo so we're making things happen around here that's right it's it's really happening speaking of it really happening so the reason we have you on john is is uh uh as richard was pointing out several months ago we had we had uh we had ansi and james on uh to talk about the circle of code and kind of how and part of that you know the circle of code is one of the many notions we have running around here that like hey if you like doing custom written software and also delivering it and you want to run your business with custom written software like here's here's all of the the stuff in a circle because it loops back so you can approve your software that you should be interested in and uh you know pivotal cloud foundries involved there and uh concourse here and there and track like it is a very nice way of of putting most all the stuff on the board that helps people do their software and part of that is uh a lot of the speed and flexibility and and otherwise awesomeness of of a cloud native approach comes down to the uh not all of it but but is created by the use of containers for a lot more flexibility and things like that so we discuss how pivotal cloud foundry relates to that and does that and uh you know you've been on the

show uh i think uh i think one of the live to tape recordings that's uh SpringOne platform or platform SpringOne sp1 and uh you you sort of uh reminded us that you see a lot of uh container stuff out there so so we thought it'd be nice if you came on and kind of spoke to that that area like what's what's going on with containers out there in the field how do people think about it what do they have up and running and how can we think about that part of the uh the overall circle or trapezoid process of code um yeah i think there's a lot of different ways that people are using containers especially enterprises because many of them are still you know recognizing that this is a sea change in how the technology is going to be deployed for enterprise use and i think many of them are in different stages of maturity in terms of making that evaluation as well as and actually rolling it out and the way that i see people or enterprises rolling it out is generally falls into one of three patterns um one is this sort of totally diy um approach where they will cobble together something like a ansible or puppet and um and maybe some terraform for provisioning combined with maybe like a vault or something else for secrets management and you put about do you know do this for every replace every need you have with the technology cobble all those technologies together into a single sort of diy platform and then deploy that as the thing that is going to both run manage and produce the containers for you so that's sort of the the first approach the second approach is this more like tool-based one where people delegate a little bit higher up the stack so instead of trying to do the provisioning and the allocation and the scheduling and the orchestration themselves they're going to delegate to say something like kubernetes or a combination of kubernetes plus some stuff that they wrote um or maybe even a um a custom scheduler like maybe they'll throw in

mesos or or something like that but the point is who are the uh who are the people that that that you that are like building this stuff like what how would you characterize them or is it just all over the map it's really all over the map i mean the if i had to draw if i had to draw some characterizations it's generally what generally winds up happening is that some executive who's been brought in for innovation reasons takes a look around and says wow things are really messed up here we could be doing a lot better than we currently are for getting software into the hands of customers you know because that's how we make money is delivering features and products to people and they take a look around and they say you know what we need to up our game with how we're going to do this so they maybe do something like start an enterprise innovation group or they find some team members that seem kind of smart and they put them together in a room and say develop our enterprise strategy and how that you know that's sort of one mode of it and that usually leads to uh disaster because that group is kind of isolated just developing stuff they're not going out and talking to everybody else in the company who is part of that deployment pipeline and understanding how software moves from i have a business idea to it's running in production and so they usually converge on our solutions that simply sort of shift responsibilities around and give you some of the benefits of something like a container but they don't necessarily produce a they sort of miss the forest for the trees they don't look at the bigger picture they just focus on like making it really easy to operate something which is the you know it's the job of a container is to be a really good isolation tool but there's so much more to the story of delivering software than being a really good isolation tool right there's there's so much more involved in the delivery pipeline besides the tiny tiny slice of yes i'm going to be good at operating um the software in an isolated way for my other things that might be running yeah so so like like like like

one other sort of like uh who are these people question like i i when i encounter like diy stuff like we have a um i mean i'm sure richard knows but we we have we have a super fancy white paper coming out that kind of walks over uh tips about building diy platforms and you can guess being from pivotal the answer is don't do that but you know it kind of it kind of walks just a one page white paper that says don't do that i mean ends yeah i should try that for for a one of those ignite talks at a devops days once but anyways uh you know it it walks through there's there's uh there's several people and organizations we've worked with who've gone through this life cycle and so it kind of like collects together and aggregates the process they went through the thinking and the uh the business and all the stuff that kind of gets to that bigger picture you were talking about but so we have that as a thing and and numerous other stuff but um i was trying to i always try to think back to when i was a developer in like the early 2000s like the we would sort of cobble together things like i think we at the time we were doing a um uh it was basically an asp but a sas application that used like jboss and oracle and we had to spend a lot of time like wiring that up and doing stuff um and i was also trying to think of like where did we like research all of that stuff right like it's not like we went out and it was like hey do you make an asp in 2004 here's the document of how to do it do it and so you know i'm i'm curious like nowadays like like when you talk with these people and look at yourself like where like what are the resources available for like here's how you build that big picture of stuff like does that idea exist out there at all or like yeah i mean i i i gotta say i don't think that so different enterprises are different but they're not that different but the problem is that everybody thinks they are really really different so the you can talk to one at least from my perspective um there's the sort of there are tiers within very

large companies um that they fall into so you can imagine that the number one bank or the number one insurance company in the world is probably different from the number ten thousand bank or the number ten thousand insurance company but the number one bank of a number one insurance company is not that different from the number five or the number ten insurance company there is sort of a power law in effect there but they're they're all roughly in the same um in the same tier of needing to care about the same kinds of things of a number of applications they have and so on so they may they may have totally different revenue and you know things like that but in terms of the way of the mode of things they need to care about for getting to a stage where they're getting that efficient software delivery they don't they're not really that different so that means that you would think that because that's true that that would mean that the industry as a whole or the enterprise system as a whole has kind of converged on good ideas about how to build these things especially if they're all off in a corner building themselves but it turns out it's not really true because a lot of them view the way that they're building those container architectures to either be proprietary details um that are relevant for their technical success and they don't really want to be speaking about that stuff at conferences or at least most of them don't so that's sort of the first uh the first reason that it's maybe hasn't converged i think the second reason is it's it's really hard to do it and most people that are thrown in a room with a bunch of other enterprise innovation people are not going to through luck or coincidence or chance arrive at a software delivery pipeline that only happens in the crucible of actually delivering software and iterating on that many many times so you're never going to get to yeah i wound up with a great software delivery pipeline by sitting in a room and imagining what that would look like and you know throwing some random technologies together and hoping it sticks like that only works when you have the expertise and the experience and the diversity of the

kind of folks you've been working with to build that in the first place which you know i think probably i haven't read this white paper that you're referring to but i imagine that um probably one of the benefits of having a platform like pivotal is that we have the benefit of that expertise and that background to be able to point to other customers and say those kind of things yeah i mean you mentioned two patterns that kind of completely diy and then kind of mixing components and i guess you alluded to there there's no one canonical like hey just build this reference architecture and that's what a diy platform just looks like from startup to startup or whatever because the technology is so mixed but what's your third pattern you see there i think the third pattern is an actual platform so you rather than say cobbling these things together in different levels of responsibility and then maybe throwing some stuff on top of it that you wrote or writing the whole thing yourself the sort of alternative to that is look at solutions that provide that platform capability out of the box either because they advertise themselves as platforms or because that's just what they do whether or not they call themselves that so you know cloud foundry is one example that seems to be getting a lot of market share at least from my perspective which admittedly is biased because i'm inside of pivotal but um but at least with respect to the financial institutions that i work with and that's my particular area the uh they're really looking at this in a serious way because they understand the one at least the uh the eventual customers of pivotal understand that this doesn't work to do it all by yourself it doesn't work to do that without being through the crucible of experience and getting the battle-tested battle-hardened version of a platform that might not otherwise exist so that's that's kind of where pivotal adds a lot of value with respect to offering that specific product so you don't really get that if you are doing it yourself it's not that you can't do it yourself you certainly can but it takes a lot of energy a lot of time a lot of

resources and that's all time that your business could have been spending making money instead of building something from scratch right right one of these you know what could versus should what you should be doing there so i'm interested in your experience in one particular area here so you know from my own experience from what analysts say what users seem to say it seems like we're kind of all in agreement to most extent the point that containers make a lot of sense on the dev cycle right i mean it's awesome that i can load a container and get a mysql box or i can pull down certain components without even thinking about it that makes development a heck of a lot easier that's awesome can make on a spontaneous test environment spin up much much quicker than spinning up 50 servers so kind of test cycle but there's also kind of a consensus that hey when it comes to going to prod you know either that should be the output artifact of a continuous integration process that pulls in base images and loads dependencies right and packages it consistently and then maybe if you decide to go to production that would be the artifact that came out of ci versus a developer hand lovingly handcrafting their their docker file and pushing that image to prod what do you see as the fit for a container today in a large enterprise if you were going in and saying hey look this is the great way this is going to accelerate your delivery what would you say yeah i mean i would compare it to maybe 10 years ago 15 years ago in like 2002 if you were part of a software development team your software development team probably included a person who worked with the developers whose job was to take their output and produce a workable software artifact and then we realized well you know putting a human in charge of that isn't a great idea like it would be better if that process was automated and consistent so we wound up with continuous integration right so now it's 2017 and we're kind of back in the same position where we're saying you know what developers you're going to be responsible for packaging up your container and shipping that to operations and

there are a lot of there are a lot of enterprises that are seeing that as they're saying that that's a good approach or that's the approach they're going to try and what we usually find is six months later they realized that wasn't a good approach for the same reason that 15 years ago we realized that not automating that not having that be consistent repeatable and um and robust is a good idea or is a bad idea to not have that so i think i think that's the parallel i would draw is if you like continuous integration you think it's a good idea but you should also probably agree that packaging containers in a way that requires any kind of manual input from a human being is a bad idea that container is going to eventually wind up in production because you don't have the repeatability you don't have an automated process that does it for you and you know kind of even worse if you want to make changes and you're expecting a person to be responsible for making those changes to the like base layers for security reasons or other otherwise then that means that now you're putting it through a human process again right and that's exactly what we wanted to avoid with something like continuous integration we wanted to avoid the uh the you know fallibility of humans and getting a process exactly right and give that to a computer instead make the humans do the stuff that's hard for computers like figuring out what a good architecture should be or how to uh how to deliver value in the form of software those are all things that computers are terrible at but that humans are great at but now we have humans doing things that computers are really great at so and humans are much more expensive than computers now so it's a little confusing that uh it's a little confusing when people arrive at that sort of logic that it's a good idea to have a development team be doing the packaging or even the operations team be doing the packaging that's something that continuous integration or some kind of thing like a platform should really be doing for you so cloud foundry has answers for that specific question we bake in a

process that makes it possible so that when you uh when you're an application development team and you say please you know please make me a running piece of software from my source code there's a container at the end of that process but you don't care about that it's an implementation detail you just get working running software so that's kind of the end state that we hope enterprises arrive at is you're not spending a whole bunch of time making humans do things that a computer should be doing anyway for repeatable reasons so so then you you you've hit on a lot of uh this thing i'm about to ask you already but like just to kind of pull it together in in a bow so like you were mentioning you know how do these things start like you often uh someone comes in and wants to improve how software is done and you gather together your uh your team of like whether they're uh ward larry and like uh cowboys or pioneers or or you know you're you're uh you're ninja rock stars or whatever ridiculous term you want to use right for uh someone who has the technical acumen and curiosity to uh investigate doing things in a new way um so if you were like leading up a team like that what would be your uh sort of like sort of like suggest your your strategy for doing it like what you know would you like do a bunch of pocs and write something or like and then like but what would you do if you were given the chance to run one of these uh how do we do the new thing teams yeah so i mean the first thing i would do is not decide i would not let my team be able to make the unilateral decision about how things would work for the rest of the company certainly not without a extremely high degree of collaboration with the rest of the company and understanding their problems and what our pipeline looks like now and how we're going to make that better um it's way too easy for some group that labels itself innovation to come up with some kind

of solution that gets thrown over the wall to everyone else but it's not in any way tied to the delivery of actual business value like you have to get buy-in from people that are doing the real work on the ground that this is going to improve how things work now it's you know sometimes that change does need to happen with an executive sponsor sometimes it is more top-down but it just doesn't work if you hold everyone at gunpoint and say uh you know transformation is happening get on board or get kicked out you have to like you have to evaluate and develop your process by looking at what exists and then understanding how you're going from the current state to this new idealized version where everything is uh super whiz bang and you have repeatable reliable and robust software delivery processes and it's way you know uh i really like p lander z but my other favorite absurd japan for whiz bang but yeah that's that's a it's it's almost uh it makes me upset at myself that i didn't think of that but i didn't even think of like a force of what you would do is uh if you're on one of these teams your first assumption is that the the rest of the company is your user and company i mean in customers your users and customers so it would probably be a good idea to go out and see what they want and what works for them like i get them very early on and and continuously involved in the uh the uh the process of doing it which which i mean i'll i'll i won't to really i'll let you get to the rest of it but that's that's one of the sort of uh is the word precepts or one of the principles that that we often espouse to people is so if you're doing this the first thing you need to realize is you're building a product and if you're building a product you have customers and users so as you point out you should probably start talking to them and figuring out what works and doesn't work for them so so then what would be the what would be the next sort of things that you would focus this team on yeah so you know i i think if you were in one of these enterprise innovation

groups you'd probably um you probably hear from different groups that they have different needs so developers are different from operators who are different from the business people who want to deliver value right so so they all have different needs but they're all part of that overall pipeline and it's your job to understand how that pipeline works at your company and how you're going to change it and sort of what level of disruption are are you charged with or what are you able to do in the time frame that you have right like you're not going to upend how a enterprise company delivers 10 000 software applications in a day a week or a month right you're you're that's going to be a gradual process so so the answer is not let's figure out how i can make this applicable to everyone and then push a button that flips everyone to the new mode or the new way of doing things it's what's the what's the transition path that's going to get me to that end state for everyone or for the subset of everyone that's relevant how do i do that and that is a much more gradual one day at a time one application at a time one infrastructure group at a time kind of approach so you you begin there by kind of identifying a slice through the value pipeline that uh so that is you know take some business sponsor take the application that they're responsible for take that application development team and take the infrastructure people that they work with so carve out that slice and say you know what would it look like to do this application or these groups of applications together what does it look like to do that in this new way of thinking whether that's let's throw some containers at it and see what happens or let's use a platform whatever that approach you're deciding on is you have to start small you can't like unilaterally apply it to everyone now where it gets tricky is you take an approach like well the unit of delivery that we're going to make everyone use as a container then we go back to some of the problems that we talked about before where it turns out that that's not really a sufficient level of abstraction to uh to avoid having to shift some of the

responsibilities around and all what you don't want to do is just be in a position of moving responsibilities from one group to another that doesn't really make any that doesn't really make anything easier that's just shuffling the deck chairs on the titanic right you want to actually move responsibilities out of the pipeline all together so that they become a computer's job somewhere instead of making more jobs for people make people have the hard thought intensive jobs and not the things that should be easily repeatable easily automated and the things that are driving the actual value through the value pipeline those should be uh there should probably be human jobs and not computer jobs well well on that and that point in particular just so i can verify the rewriting i'm doing in my head of what you said it's basically uh so when you look at all of the tasks slash responsibilities that which is to say staffing that you need uh you hear a lot about uh about organizations changing and stuff like this i mean i'm i'm guilty responsible or delightfully helpful depending on your of the world about writing up and making that point a lot but what you would say is like one of the things you should be cognizant of is it's not really just about moving people around shuffling people but really what you should be doing is seeking to automate as much of that function as possible and i i would even suggest a uh uh like an automate first thing is like our first assumption is that we're going to automate everything and if you don't want to automate it you have to have a good reason not to do it which may be that it's unautomatable if that's a word but but i i i mean tell me if that notion comports with what you're saying but that seems to be the thing is like don't just assume you're moving people around assume that you're going to automate stuff uh over that so you can focus on other things right i mean i think it's a safe assumption to start with the idea that many like so one of the one of the stories i always like to bring up is if you look at how we deliver oil right now so russia ships oil

through a 4 000 kilometer pipeline it's called the truzba pipeline truzba means friendship in russian and this goes from the oil fields in the like central west of russia to germany and it's 4 000 kilometers long and it takes them about 45 days for oil to enter one end of the pipeline and go to the the other end of the pipeline so billions of barrels of oil are traversing this 4 000 kilometer pipeline in about 45 days 50 days but we can't deliver software and an enterprise to a production server that's in the next room over in less than 60 90 120 days for some of these people so like what so the question is like where in that pipeline is the holdup why does it actually take 120 days to deliver software why does it take this long and when we look at why does it take that long it's usually because there are large numbers of handoffs of responsibility between uh between people or groups or teams inside the company but really those handoffs are not what's adding value it's the whatever the person's doing that's adding value right like giving a responsibility to someone else adds no value what that person does to the software or the artifact of the process whatever it is that's the thing that adds value so you look at what those things are how many of those things could be automated those are things that are probably i are probably turn out you want those automated for applications that are cloud native for example you want them to be easily repeatable you want them to be done by a computer because you're going to be doing it a lot of times in a lot of different places and what you don't want to do is have to pick up the phone and call alice in it to ask for a new server to be provisioned if that is a process that takes seven days right you you want you need that thing to be automated if you want to be able to short that shorten that pipeline right now that makes sense yeah so one more container question

before i want to pivot you to something else but so a lot of those things you just talked about around automation and and thinking of your stakeholders especially as you're doing kind of incremental transformation are you seeing enough attention paid on the day two ops story of these things i think that's where we sometimes can get excited about tech and we deploy stuff and as you say sometimes it just gets handed over and becomes tough to manage so how do you see shops who are getting going on some of these products as they think of their stakeholders like hey those ones who have to run it and hopefully they're in a you build it you run it sort of product team model maybe not but what do you do when something breaks when you do have all of a sudden you know a thousand microservices and twelve thousand containers and there's a zero day linux bug how are they deploying that out there i mean cf were spoiled because i can see every stage rebuild a container with the latest build pack and have all the latest bits and i'm fine i don't i don't even need to go upstream but how are you how are you seeing companies take into account the ops story when they think of this deployment pipeline when they think of all these stakeholders and trying to do software better yeah i mean i think the answer is that's why you see a lot of people who tried to build it themselves six months later like yeah it didn't work let's try cloud foundry and see where that gets us uh because six months is about how long it takes for that next few release cycles to happen and then they realize oh we were operating software that we don't really have a plan or a strategy for there's no if we know how to operate it but we don't know how to keep operating it after it's already out there and the tooling doesn't help you with that and that's the kind of stuff you're really only going to discover after you've gotten it all the way to production and you've been through a couple of cbes there are like good ways and bad ways of doing that but without the without that being part of your automation strategy in general and the 5 000 other things that go along with your day two operation story you're not really going to have a successful outcome in delivering value to software or at least not pass not pass the first time you do it anyway and and i think the

the areas where people fall down the most are you alluded to one which is that like zero day patching sort of situation but it it even if there isn't a critical problem even if there is no zero day that applies to you there's best practices you're going to want to be able to achieve anyway so for example eventually your ssl certificates will expire so you know what does it mean to rotate your certs on your platform or for your containers or for your applications is that automated or is that manual does someone have to remember that the certificate is about to expire is there like a google calendar invite somewhere about you know six years from now you better hope that that person is still employed with the company or else everyone will discover that their ssl no longer works so that kind of stuff is is the category of things that don't really show up on the radar when you're building this stuff but it's absolutely critical to get right when you are running in production it matters less if you're running in development because you're blowing away the infrastructure all the time or if you're just running a science experiment it also matters less but if you're running this if you're a fortune 500 and you're running this stuff in production you really need to have your ducks in a row at least for the first three applications you're deploying on here you need to get that right or otherwise really the experiment will be a failure yeah that's great good points i want to you know let's be a couple more questions for you you've got an internal paper you put together which i don't know what to do with yet i'm going to figure out a way to promote it to the masses but uh it's about some of the app profiling stuff for pcf because a lot of what we do isn't just hey new company or company put all your new apps here it's a lot of you know re-platforming it's modernization it's taking sometimes even just picking up these modern apps and moving them to the platform and this paper was i think you trying to say hey as you have sort of intense monolithic apps you have some lightweight apps you have different things how can you map from a kind of app server sort of model to an application instance model the pcf uses can you tell me a little bit about a little

bit about where that came from and some of the mental model you put together there sure yeah so this came about the paper came about because i kept working with customers who would raise the same questions again and again namely i'm really interested in using a platform but i don't understand what does it mean for me when i want to move my monolithic application over to something like cloud foundry or for that matter i have a bunch of microservices that are running somewhere else we're not running that great in this other location i'd like to move them to cloud foundry to kind of leverage the benefits of a platform and accelerate how i write and deliver software and and for a lot of customers it's we use application instances as our you know metric of how many um how intensively you're using cloud foundry and that's that's sort of the the metric that we use but for a lot of customers that's the first time they've been exposed to the idea of instances or the idea of ai's as a metric for the intensive uh the intensity by which they're using some software product so i wrote that to kind of spell out for them what it means and how to map their existing ideas into ai's and it turns out for most cases it's an extremely simple one-to-one conversion basically if your app is like most most applications if it's io bound that is if it is constrained not by cpu but rather by how quickly it can receive and send requests typically http but it might be something else like maybe it's over tcp or whatever but but typically http requests are io bound so if you uh the rate at which you can process requests is usually limited by the rate at which you can receive and send network communications so that's what we call an io bound application if your application looks like that then it's pretty much a one-to-one conversion of however many processes you have running today in your on-premises data center

is probably how many you want to be running in cloud foundry as ai's so if you have 10 jbms for some application you probably have 10 ai's in cloud foundry what's different is when you have applications that are not io bound so if your application is constrained instead by the cpu that it wants to use or the memory that it wants to use that's a different story so then the uh then the document goes on to describe some ways that you might um that you might consider mapping your existing and your existing uh counter processes into what might be ai's so i offer some guidelines there but in general one example would be something like if you are doing you know cryptocurrency validation so you uh you have a blockchain and you want to make sure that some transaction is actually part of the blockchain then you would want to run something that's pretty cpu intensive you would uh there you'd be you'd be doing a quick check on that transaction but when you're adding a lot more transactions to the blockchain or you're you know mining for cryptocurrency you're going to be doing a lot of work relative to the amount of memory or the the size of your instance and then and that means that you sort of have to do a little math about you know exactly what does that mean in terms of the resource allocation and making sure that uh making sure that what you had before is going to map to ai as well and cloud foundry is really good about handling workloads in general so if you have like really really cpu intensive stuff next to other really really cpu intensive stuff cloud foundry will notice that and make sure that those workloads don't uh go next to each other so they'll always get they'll get the workload that they should be getting um and the resources that they should be getting to do that workload um but cloud foundry also kind of assumes that most stuff by default is io bound because that's usually the case that most most things are io bound they're getting network requests

from somewhere else and they're doing something to that request and so so when it's not but it doesn't look like that we wanted to offer some advice about what does it mean for my application what does that look like and so that was the purpose of the the white paper and i would think some of that factors into things like auto scaling and being able to quick spin up and and decontract application instances that you might have had 10 jvms or 10 you know web core iis sort of processes but that's because you modeled it for the peak so you have to still do usual i guess usage profiling and try to get people to start with what they need not what they necessarily had to use before right exactly and a lot of cases you know like we talked about before because that pipeline it was really long and difficult to traverse if you had to get more capacity if the way that you got more capacity was i need to call up alice and it and ask her to provision me some more space and that takes three months well guess what you're probably going to err on the side of saying you need a lot more resources than you actually need so there's probably a lot of baked in inefficiency already with some of these companies that have these slow enterprise deployment pipelines because they have no choice except to over commit the uh the amount of risk or over commit on the number of resources they say they need versus what they actually need and when you go to cloud foundry you might just get some savings for free because you can just start with what you need and scale up or down as you need and on demand yeah bringing it home is why i think containers help because we know we can spin up new application instances in three seconds or what have you which is much different than building a physical box or even spinning up a vm so again some awesome value when the platform's using it and maybe not throwing the burden on the on the devs or ops staff exactly and you know the last thing you want is to make if you're the enterprise innovation group and you're the svp who's just been hired to make a big splash uh the last kind of splash you want to make is to have everybody else in the company really mad at you for what you proposed yep well thanks for being on this episode this was this

was uh this is really helpful and interesting we'll have to as with most thrilling helpful white papers we have around pivotal we could probably make it public we'll have to see what what we can do with it we got a lot of uh things scurrying about that sort of are hidden around in google docs somewhere but uh i'll have to at least read it so i'll benefit bully for me anyhow uh where are you uh if people wanted to contact you you gotta you got like twitter and stuff like that where where can people find you yeah i'm on jxxf on twitter uh you can also just email me at jxf at pivotal.io uh and you know if you see me at a conference or whatever feel free to come say hi and we'll have a nice chat about what the inside of a hairdryer looks like oh yes i'm gonna have to go verify that uh pretty soon here well as always this is Pivotal Conversations uh you can find uh us by going to soundcloud.com slash Pivotal Conversations we're in itunes and overcast and we we have one review there about our most excellent hr uh discussion in there but if you if you like this show it's always good to go at least add a rating or a view in itunes or hit the recommend thing in overcast but really the most helpful thing is just to uh subscribe to the rss feed which you can find there or uh tell a friend about it uh and i'll put the show notes uh we mentioned several things here and i'll put them up at cote.io slash conversations 48 and then you can look up all the uh the amazing stuff we have and with that we'll see everyone next time bye bye

Tanzu Talk · 🍕 Get more pizza.