That Cloud-Native Lifestyle

August 26, 2015 Coté

sfeatured-podcastAndrew Clay Shafer is back for a discussion of what Cloud Native means, and wood-paneling. We discuss what we see as “Cloud Native,” the full stack:

1. Cloud Native Application Frameworks
2. Cloud Native Runtime Platform
3. Cloud Native Operations
4. Cloud Native Empowered Culture

PLAY EPISODE

SHOW NOTES

TRANSCRIPT

Coté:
Well, you know, when I was growing up, my grandparents on my mother’s side lived in Austin here. We would visit them all the time. It gave me this nice perspective on the growth in Austin because they used to live in the middle of nowhere and now where they live is comfortably, what we euphemistically called North Central Austin. Which is a funny phrase. I’m sure some real estate broker came up with. My grandfather, he had this awesome den which I think ruined me in a good way about wood paneling. It was full of wood paneling.

My vision of sort of like perfection in life, a situation you want to pan out, is first of all you got a den. That’s a whole thing right there. Second, it’s covered in wood paneling. I have noticed in the video calls that we’ve been having recently, the house you’re now in there over in the California in Los Angeles as they say.

Andrew Clay Shafer:
In the California.

Coté:
It’s full of wood. It’s got wood paneling everywhere. I’ve been waiting to ask you, has this introduced to sort of sense of accomplishment and calm for you? Do you not react to wood paneling the same way that I do?

Andrew Clay Shafer:
I’m not sure confidence and calm is the thing I’m going with. It’s a nice room that I’m sitting in at this moment.

Coté:
Do you feel like you need to Pledge it a lot or polish it? How does one care for all that wood?

Andrew Clay Shafer:
I think that the weather and the way that it’s setup, it doesn’t need a ton of care. It’s kind of cured if you will. This is the house that was built in 1926. It’s going on a hundred years of this wood paneling I believe. It’s nice. I’m surrounded by wood shelves. There’s actually also a stained glass window on one side of it. It goes into the house.

Coté:
Oh yes. I remember you showing me that. That’s very nice.

Andrew Clay Shafer:
Yes. It’s a nice feature.

Coté:
Does it feel like you’re kind of moving around in every kind of mid-budgeted sort of Hollywood entertainment thing often which is like just filmed in the area, right? It seems like you’ve got the ranch housing around there. It must be very reminiscent of lots of movies and TV shows.

Andrew Clay Shafer:
I’m sure there’s a bunch of 90s shows that are filmed within, however far from here, walking distance maybe.

Coté:
Then you were down in Orange County this week. You had a whole Veronica Mars feel to exist.

Andrew Clay Shafer:
No, no. I went all the way to San Diego.

Coté:
Oh, sure. You drove through that? I lumped it all of the same with, just like I treat all of New England as one sort of big city. I think of the kind of LA, Orange County, San Diego thing that just sort of like one gigantic expanse of stuff.

Andrew Clay Shafer:
Here’s a little thing before we get on to the real meat of this matter. I’ve never seen advertisements for Maseratis on TV before. Now, in fact, I have.

Coté:
Yes. This is like I felt like the Austin Tech community had arrived when we had those grotesque Dice billboards of like geeks in their Jockey shorts around town. It was a big moment for us; big times.

Andrew Clay Shafer:
The times, they are changing. I did drive down the way. It’s actually the first week of school. I dropped my kids off at school. Drove from Los Angeles to San Diego. Spent 2 hours at a Gartner Conference and drove back to pick them up from school. That was a very productive day.

Coté:
Was that Catalyst?

Andrew Clay Shafer:
That was the Gartner catalyst. I did a panel about private PaaS. Is it ready?

Coté:
Were they banding about the phrase Cloud Native and things like that? That’s been the popular thing nowadays. That’s a good launching off point.

Andrew Clay Shafer:
I think we said that word and a few other buzzwords along the way. There was probably microservices and continuous delivery, and DevOps mentioned as well. The main thing that I think is a win here is, especially from the perspective of what we’ve been trying to do is that Gartner finally admitted that there is such thing as a private platform as a service. Then they had some interesting data that they said 52% of their inbound queries about platforms are about private platform as a service. That’s interesting validation.

Coté:
Back when I was at Dell doing Cloud strategy, getting any information about the private PaaS market was really hard. I remember Gartner has a category called CEAP which I always inserted an R in there to make it CREAP because I can’t help but make a joke. It would be nice if they converted that over more. Instead of being middleware in application stack, it would be nice to track that as its own thing.

Andrew Clay Shafer:
I think that the market’s kind of forcing their hand in that regard. Obviously if you’re spending time talking to me, you know how much I like the word PaaS. How I basically tell everyone we’re going to stop saying that. They’re kind of, they’re catching up.

Coté:
Speaking of trying to reframe what PaaS is if you will. There’s a whole lot of I don’t know what you would call it. Fun Chutes and Ladders when it comes to the phrases used for this stuff. I think we and the people we talked with here at Pivotal have come up with some good framing. We still use and I still like the idea of a cloud platform, right? There’s this idea of Cloud Native that we’ve been dividing into essentially 3 layers. Basically the application and framework and its sort of, where you have your 12-factor apps and microservices and things like that. Then you’ve got this layer in the middle that’s the container orchestration which of course you can reverse engineer that. That implies there’s some containers involved. Then the layer below that is essentially the infrastructure automation layer. It’s starting to feel like a good way to divide up what something you and I, and other people have been talking about a lot. PaaS is a lot more than just sort of like that first layer. It’s really a lot more I should say. It really does get to that point of why we always talk about a platform and the need to have all these different layers in there.

Andrew Clay Shafer:
I think the acceptable definition of PaaS for me is this sort of API-driven deployment layer which you definitely want to have. If you want to do something like microservices or continuous delivery, then you’re going to need to drive down the fixed cost of delivery or fixed cost of deployment. You probably going to want to do that with some APIs. At some point whenever you build to do that, it starts to look suspiciously like what people will call PaaS. That “as a service” thing whatever that is, is an application as well. How do you deploy that thing? How do you manage that thing? How do you upgrade that thing? How do you operate that thing? That’s the stuff that’s at the layer below. This kind of infrastructure automation layer that I think, right now there’s no other project that has anything close to what we’re capable of doing right there. Then above that layer where you have the platform or the “APIs for deployment”, there’s a bunch of architectural patterns that are emerging which if you want to kind of reinvent the wheel, you’re more than welcome to. The things that we’re able to get people out of the box right now with Spring, Spring Boot, and Spring Cloud is basically like this microservices Lego pieces that you can kind of put together.

Many of them had been used to build whatever Java background or applications that you’re already using. The Netflix is famous for having a third of the internet traffic pretty much every night. We’re actually using their stuff, and they’re using our stuff to kind of build the future. We might as well take advantage of that code that’s already there.

Coté:
I think swinging through the publishing schedule. Wow! We’ve actually published the last 2 episodes of this podcast, were all about Spring Boot and Spring Cloud.

Andrew Clay Shafer:
That’s my boy, Josh Long.

Coté:
Exactly. He’s fun to talk with. It’s interesting to sort of understand Cloud Native through the lens of Spring Cloud basically. Then the kind of setting up that Spring Boot does for you because it says I don’t know. I’m an old Java person. The phrase opinionated always feels like the old lores of the mid-2000s to me. It’s a nicely opinionated way of how you go about accomplishing all that in Java. It really demonstrates the Cloud Native lifestyle.

Andrew Clay Shafer:
I believe in having strong opinions.

Coté:
You know what that reminds me? You tweeted a little while ago, was it 2009 or 2008 that you sort of like turned your back on Java. What did you mean by that? What made you gave up on it? What made you start looking at it again?

Andrew Clay Shafer:
I don’t know how deep we want to go into this rabbit hole but there’s a period in my career where I was primarily writing a Java code back in the day. The first time I ever wrote Java was right when JSPs came out. Everyone is so excited because now you no longer had to embed the HTML in your servlet code. You could now embed your Java code in your HTML. That was so much better. We kind of all know like whatever crazy tangled disaster that ended in. Then the J2EE stuff came out and whatever is going on. I ended up working for some startups that were primarily Java. The funny thing was along the way I was doing all this kind of computational science. That was primarily C, C++ and Fortran. They always had like this weird disdain for the Java developers which I thought was odd.

Then after seeing how a lot of that stuff was built and some of the things that were going on. I like Java in a sense but the sort of the culture around it was very stagnant and confined to me. When I started some of the Ruby stuff and working on Puppet, and going to the Ruby conferences. Then it was just really easy to get enamored and kind of caught up in the enthusiasm of that community. That made me never want to really do Java again. It’s one thing with technology, but the community itself was not inspiring at least to me at that time. There’s this alternative community that was really trying to move things forward and push the boundaries. Things like Rails, and Puppet, and Chef, and the rest of that are all kind of part of that narrative. Now you’re seeing explosions of languages and people are doing things with JavaScript and the rest of it. When you look at that full cycle, lots of people that are my friends that built some of these big startups, big web applications, they kind of all gravitated back to Java. Many of them gravitated back to Java as this reliable kind of battle-hardened way to solve these problems at scale where it’s much harder to kind of coax the Ruby one time to do that.

Coté:
Definitely you can see that in the RedMonk where I worked a while ago. It has always done a good job of pointing out that sort of return to Java if you will which is always encouraging. You’re also touching on something I’ve been thinking about a lot recently as I’ve been typing up this series of like what’s the Cloud Native journey look like. Most of it is like a lot of as we would say, cultural and process, and things like that talk. It’s not too tightly connected to the technology. I’ve been reflecting on because you were just saying like I guess you could call it what went wrong with Enterprise Java. I say Enterprise Java apart from Java very specifically.

I think it’s because they didn’t really, and I should say we because I was in that bucket. We didn’t spend enough time on the non-technical aspects of things, right? All the way from sort of like architectural concerns, to sort of process, and how you organized teams, and how you think about all of that. It also, I think to some extent, explains why in the DevOps space and increasingly in the Cloud Native space, everyone is obsessed with culture. They talk about people problem so much because whether people implicitly remember it, or I should say explicitly remember it, or it’s just kind of screwing around in their subconscious, they kind of remember that like the people part is really important. We should spend a lot of time on that. It doesn’t seem like in the Enterprise Java space enough time was spent on that. It sort of explains why we spend a tremendous amount of time on that in the sort of current era that we’re in.

Andrew Clay Shafer:
I think there’s a bunch of things that are happening. Obviously, the cultural stuff is something I spend a good amount of time talking about. There’s a kind of pendulum that swings on the DevOps community where on one hand people say, “Oh, you know we need more culture.” Then people say, “Oh well, like everyone’s talking about culture. We kind of need to talk about tech.” It sort of swings back and forth. Then I would say, this applies to the automation space and really kind of all 3 layers of what you just setup when we start the conversation. I think that the old mentality which I’m going to say is transitioning in the Cloud Native mentality was to just do whatever. Java automation-

Coté:
That’s a good way of putting it.

Andrew Clay Shafer:
… all the rest of this stuff from kind about last generation of work is like, “Let’s just do whatever. We’ll put the features into that thing.” That’s why you end up with these kind of bloated, unmaintainable, unmanageable applications. I think that at least the way I’m going to do the things moving forward is have much stronger opinions. I was on this panel at Gartner and one of the things that was a bit of intention with some of the other panelist is that they’re arguing that their platforms will just let you do whatever. I think that, and I believe this very strongly that ad hoc automation is actually a problem masquerading as a solution. That you just end up with more problems or at least kind of proportional amount of problems going forward if you don’t look at how all these things integrate from the patterns of the architecture, to the patterns of the infrastructure, to the patterns of the automation. All sort of in the integrated fashion. If you’ve given yourself the leeway to do anything, then you have to do anything to recover that, right?

You can’t make an enforced promises about what you’re actually going to have from a behavior perspective, from the scalability perspective, from the reliability perspective, from the security perspective. I think that what’s evolving and what I see as a kind of Cloud Native mindset in architecture is … This is actually pretty explicit if you listen to people like Adrian Cockcroft, from Netflix talk, he’s like we didn’t give self-service automation to just do whatever. We automated simple patterns. We automated predictable patterns. It’s that array of predictable patterns, it is array of kind of battle-tested architectural paradigms that I think submerging it as the new standard. That’s what’s exciting. You know this thing will scale. You know this thing could be managed. You know this thing is secure because you constrained what you’re going to allow. In return, you can keep stronger promises about that. One of those promises is self-service. Other promises are this long list of “abilities.” I think that’s what’s exciting.

Coté:
To use my sort of like ever-expanding pigeon language for understanding the world. It’s sort of like there is a certain amount of local optimization that destroys the big picture that goes on when you have that just do whatever mentality. I think, I’m not often the one who likes to kick sand in other people’s faces, but if you look at it with a lot of the conceptual and product-based competition of ours is up to, they tend to focus on just one layer of that stack. We neatly sorted it down to 3 layers. It’s sort of like if you only focus on packaging, or you focus on deployment, or you focus on the framework that you use, you really optimized the crap out of that one thing that you do. You probably do it well. In order to sort of like make sure that things work in the large, you got to look at the whole system end-to-end. When you start doing that, that’s when you start forming opinions that may not make perfect sense at first, to sort of like one node in that area. Some operator may not want something, like something, or a developer may not like something, or so forth, and so on.

You’re sort of like have that whole end-to-end vision like those 3 things we were going over, because otherwise it doesn’t really work out so well. I think there’s plenty of historic analogs like we’re just going over like Enterprise Java where there is a bit of local optimization at parts of the application life cycle. What we’re trying to do, I mean I always look at the tech industry is like 2 steps forward, one step back essentially. Just sort of like slow progress in clearing out this stuff.

Andrew Clay Shafer:
Two steps forward, one step back, one step sideways.

Coté:
That’s right, right. Then several steps trying to figure out where you’ve ended up. It’s like if you get knocked out by a zombie and you wake up late after the commercial break. You’re trying to figure out what happened.

Andrew Clay Shafer:
I think that’s exactly the point framed in maybe a little less complicated way. I think if you look at the specs on an iPhone today. That it arguably doesn’t have the best hardware for nearly any component. You can’t argue with the results in the market. You can’t argue with their experience. The experience they’ve created. I think that if you look at things more holistically in an integrated fashion from top to bottom, then the types of efficiencies and experiences you can create are very different than if you’re optimizing some component in the stack.

Coté:
Right. I think as I’ve been writing up that Cloud Native journey stuff, that’s what we’ve seen amongst our customers is they have a view to the big picture in what the end-result is going to do. They take this sort of like that kind of hockey stick-ish curve of small changes, small changes, and all of the sudden once they learn the process, and the culture, and the mindset they can just suck in all the other technologies and do things in the large. Again, it comes back to having those 3 layers of the stack that will look at everything. Which I think is hopefully that’s what this idea of Cloud Native ends up becoming. Not only the technologies but the sort of like big picture process in the end that you wrap around it.

Andrew Clay Shafer:
One of the big differences in the panel, there were a lot of things we agreed on actually. The big difference in my opinion was where people want to make opinions. How much they were willing to trade-off investing in the future versus sort of optimizing aspects of the past. I think from Pivotal’s perspective and the way I want to think about things, and the way I want to build things, I want us to be much more like doctors. Where we’re giving you something that will help you be well. This is the path forward. This is the way that you’re going to. If you want to be well, like this is how you live versus, “Hey, I’m a waiter and I’m going to take your order. Whatever you want like I’m just going to bring it to you.”

Coté:
Right.

Andrew Clay Shafer:
As a consequence if someone asks me right now, how do you do this complicated thing? That I want to install this thing and it’s got a bunch of state. There’s a bunch of steps. Then at the end of that process, this thing is setup, how do you do that? How do you do that with BOSH? Then I just say “You don’t. Don’t do that. Why would you want to do that?” What I want to build here are things that are easily recovered, easily scaled. What you just did with this complicated thing that has a bunch of order, and a bunch of state, and a bunch of steps is set yourself a lower bound for how fast you can possibly recover when that thing inevitably fails.

Coté:
Right.

Andrew Clay Shafer:
As a consequence of a bunch of these other things where people are talking about their problems with their culture, their problems with their downtime, all these other things. Half the time when you look at that … I was just at the Agile Conference too and people are talking about, “We want to scale Agile.” The reason you can’t scale is because you’re architecture is this monolithic thing. That means everyone is gated on everyone else.

If you want to scale your process, scale your architecture. You want to fix you uptime, fix your architecture. There’s a lot of these things. In some ways some of the Agile narrative probably rotated people off of this. Architecture actually matters like the day-2 cost of operating different architectures can be vastly different. That’s why I think you see this movement. I’ve argued this in some of my presentations. I just made the statement at the Agile Conference that these microservice architectures are the natural evolution of people who need to change things, move fast, and move at scale. If you don’t need to move fast, if you don’t need to be at scale, then it’s like you have a lot of other options. If you need those things and that’s the evolution. That’s what people did because that’s the best way to do that.

Coté:
I think the Agile community had the chance to learn how having good architecture helps out with one of their core tenets a long time ago which is like if you can’t test your stuff, you’re doing a bad job. Write your stuff so that it can be tested. Which sort of seems obvious in hindsight. I remember at the time it took a lot of rethinking about how you architect and divide your product out. Similarly, I think analogously like as you were just mentioning, there is a lot of let’s just call it cloud architecture principles like microservices, and 12-factor apps, and other things that come into play. Those are there for a reason because it means that you can run it appropriately and get all the benefits that people talk about.

It reminds me actually when to go look up this point in that conversation you had with Matt Curry a while ago. Where you guys were kind of joking like for years people had been telling you, high performing companies like Amazon and Netflix have been telling you how they operate. What technologies they use. Everyone’s always like, “Yeah, but you don’t really do that? What do you guys really do? You don’t really have small teams. You don’t really force people to manage everything. That’s sounds crazy.” It kind of amounts to that. All of that stuff is sort of like a collection of opinions about how you need to operate in order to really kind of be in a Cloud Native sort of air and mindset. It starts to become important to pay attention to them and have that larger view of things instead of myopically looking at your one little part of it. The whole point is like, it’s important to actually take seriously these recommendations. These opinions that people have.

Andrew Clay Shafer:
One of the things I’ve come to believe being in this industry for over a decade, going on almost a second decade now is that telling someone the truth that they’re not ready to hear, is the same thing as lying to them.

Coté:
Right.

Andrew Clay Shafer:
There’s no way that they’re going to believe you and they’ll just think you’re lying anyway. You might as well just lie to them. I think it’s exciting to see the evolution. I think that it’s exciting to see. We take for granted some of this stuff because the way Pivotal engineers is test-driven, and developed all the time, peer programming all the time. A bunch of this stuff that kind of a lot of people aspire to do. That’s the way Pivotal lives. We really try to walk our talk on a daily basis. As a consequence to that we’re learning, and we’re growing, and we’re building these things with our customers. There’s a lot of stuff that is emerging by necessity. That’s the mother of invention. If the patterns work, and you can operate it, then that’s the real deal.

I think that the past was sort of dominated by applications that didn’t really have the need to be run at these scales. They didn’t need to be necessarily be changed. There was an advantage but we didn’t have the same kind of Darwinian pressure that a lot of these organizations are facing now. This is a quote that I made before but someone reminded that I made it in their presentation with CenturyLink this morning. You’re either building a software business or you’re losing to someone who is. If you believe that, then you need to do everything you can to enable that. If you don’t believe that, then that’s fine. We’ll go back to DM-ing on this. There’s no need to change. Survival is not mandatory.

Coté:
That’s almost like the sort of first principle for why you would care about all this is. You want to become a software organization. To your point is, to some extent it’s almost a take it or leave it thing. It’s obvious to folks like us on this side of the fence that that’s a good idea, right? That’s the punch line of survival is not mandatory. It gets back to this point of and therefore if you want to be a software organization, here’s how software organizations operate and what they do. It’s not like just weird window dressing.

I was reminded of this when I was out in the field talking with a rather large company. We have this RFQ that the Pivotal Labs people did with the government recently. Where they basically, they took a pretty simple application. It would test out if you’re medications, you’re prescription drugs would conflict with things. I’m on this prescription drug and I want to have a bottle of wine. Am I going to die? It’s pretty simple but it was scoped out to be a small thing. Within 8 days, they basically built this application. It’s a good presentation that you can go look in GitHub to get a sense of like one of the better representations of what the Cloud Native lifestyle looks like so to speak. One of the things that I always like to explicitly point out to people that I was doing back in the meeting with this big company is there’s just one bullet point. Where in the first day they’re like, “Oh, then we could set this all up and get it running because we are deploying it on the Pivotal Cloud Foundry.” On a fully automated cloud platform so we could deploy code on day 1 and just keep deploying. Do all of this deploying daily and getting user feedback and information, working on it, and deploying something after 8 days because we are using this. Then, they never mentioned it again.

It’s easy to kind of gloss over the fact that like, I don’t know, maybe like the 2 and a half of the layers we just mentioned. They spend most of their time up in the application layer. The other 2 layers of contained orchestration and infrastructure automation were just like taken care of them because they have installed this platform. It was interesting going over that with this big customer because their first question was like, “Oh, but those were like highly skilled people who like know what they’re doing.” Which is true but on the other hand like 1, they have this technology in place that allows them to move fast. Then 2, like the things that the do really aren’t that like difficult. It’s just like here’s a set of principles that they follow. If you want to operate that way, just start doing those things too. It’s not impossible for you to do it. You just have to convert over to thinking that way.

I think that’s going back to like what we talked about people and culture so much. That’s a bit of the shift that has to happen in people’s mind is where not really, and this is a good thing that were saying. We’re not really saying just like install this technology and everything will be dandy. Get the appropriate technology stack. Then it makes it easier for you to change your process around to be this sort of like, ninjas, or heroes, or unicorns, or whatever the nomenclature of the day is. As you’re always fond of bringing up. As Adrian Cockcroft said, “They didn’t just sort of like birthed unicorn people from some green vat of goo. They hired them from regular enterprises and made them who they are.”

Andrew Clay Shafer:
We hired them from you.

Coté:
Exactly. There’s a tremendous amount of hope around being able to do this. I think what’s nice is that the technologies actually seem to work this time. If you have that big picture of you of putting everything in place, and kind of using them in the way that they’re intended to be used, really all you need to worry about is culture and people things. Which in comparison to some technology that’s lame and not working is a solvable problem.

Andrew Clay Shafer:
Yeah. I think this is a little bit different topic. The types of things that are happening in 2015 in a world with Twitter and GitHub make it kind of hard to sell the old enterprise legacy products that are kind of based on asymmetric access to information. The old school enterprise software business was based on steak and stripper-driven deals with a bunch of kind of used car salesman on steroids driving the marketing into a customer that doesn’t necessarily, they’re not sophisticated about the technology and there’s no way to become sophisticated about the technology.

When you have an open source project, when you have a bunch of other people that are building on the same core then it’s not a mystery. It’s not a mystery about what this stuff is actually capable of. I think that’s a big thing. Also kind of I want to dovetail off some of the stuff you just said and plug a talk that I have coming up in London at a conference called Operability.IO. What I want to talk about and this is really sort of the journey of configuration management and some of the things that I’ve seen and been through. There’s certainly things you can automate. This automation renaissance that’s become sort of driven the last few years of this. At the same time, the things that you’re actually choosing to automate, and the patterns that you’re driving forward with, have a huge impact on that day-2 cost of operations. While you can conceivably automate a bunch of that stuff, it’s not all equally operable. I will talk about what its operability and how did the architectures of the application level interact with these lower level promises from a platform to give you something that is or isn’t operable.

Coté:
When is that Operability.IO conference?

Andrew Clay Shafer:
Let me check. It’s September 20 something. Let’s see when my talk is. September 24th, and 25th in London. I have the first talk of the day on the 24th.

Coté:
That sounds like there’s a little bit of crossover to the talk you gave way back when at when was it? Configuration management camp. There was some similar ideas there.

Andrew Clay Shafer:
Yeah. At configuration management camp I talked about BOSH which going back to the 3-layer Cloud Native cake that you put up a moment ago. That sort of the bottom layer. Where here, I’m probably going to spend a lot more time talking about the top and architectures of the actual applications and the implications of choosing. It kind of goes to when you think about the goal of having something that the mean time to recover is driven towards zero. If you can get to something that you can recover instantaneously, then by definition you’re never down.

These patterns of architecture and load balancing, single points of failure just thinking about how all that stuff fits together in a way that people can make sense of. I think it’s sort of this emerging architectural discussion. In some ways it’s really been missing. Part of that is because not a lot of people have had the experiences that kind of drive you to where this stuff makes sense. If you’ve never been through the pain of actually growing a rapidly scaling service, then some of this stuff doesn’t seem to be a big deal. They’re like, “Why don’t I just do this thing. It is small. Where you don’t really have to scale and you don’t really have to move fast, then things seem like they’re roughly equivalent from the kind of automation and operability perspective. It’s really only under the load, and the speed, and the rest of these other things that come into play when you’re “succeeding”. Then a lot of this stuff starts to be a differentiating factor. I’m just trying to kind of collect some thoughts and crystallized those and provide … Honestly, a little bit of clarity, I feel like there’s this missing operability that’s trying to kind of fill little bit of this.

There’s this architectural discussion that’s happening that sort of focused on these obstructions of code. Then there’s the system architectural discussion that’s actually kind of missing from the industry. I’d love to see someone fill that out and maybe we should just organize our conference.

Coté:
As you were pointing out earlier, it’s hard to find a lot of examples of sort of everything in the Cloud Native stack. At the moment, there’s lots of conversation that’s highly optimized on each layer and there’s lots of people worried about like container orchestration, or containers, or strict infrastructure automation. Other than ourselves, there’s not that many people who sort of like have a studyable open example of doing everything. It’s hard to emphasize that people should pay attention to the big picture when not everyone is sort of like producing the big picture.

Andrew Clay Shafer:
Even if you’re not going to have like this fully integrated thing. I know lots of people, lots of places that have built their point of pipelines, they’ve built their continuous delivery, microservice to point of pipelines. Even if you’re not going to have like everything is like this fully integrated vision that the Cloud Foundry and Pivotal are giving right now. There’s a ton of value in just studying these patterns of success and failure. Failure characteristics have a huge impact on your operational capacity. Being able to plug that in versus, I mean one of the things that I see emerging in terms of DevOps narrative or whatever you want to call this sort of Cloud Native journey is moving from a mindset where we’re trying to minimize incidents to a mindset where we’re trying to minimize the time to recover. If you can get your time recovery to zero, then by definition you never had an incident. Typically the way this gets implemented is a bunch of signatures to do change control. That tends to lead to very brittle systems that maybe they don’t fail “as often” but they tend to fail catastrophically.

That’s why you see things like the Chaos Monkey. Going back to things people don’t believe, believe the code is there. Netflix literally destroys parts of its infrastructure as part of their day to day practice. They inject failure into the application, into the infrastructure so that they can be certain how that stuff will behave. How that stuff will perform. There’s a bunch of patterns that come into that that delve into whatever I’ve already been talking about. The way that these things, their architecture, they can realistically lose a third of their capacity along specific failure domains and never miss a request, and never stop serving your business. I think that’s a big change for people.

Coté:
We have a project called the Chaos Lemur if I remember. That helps out with that which is equally funny name. Now, that’s a perfect example of things that people think are like made up that people talk about. At the end of the day it’s sort of like, it’s the ultimate test. It’s a good safety test app. It’s like doing fire drills and all those other sorts of things.

Andrew Clay Shafer:
One of those things where once you’ve been initiated, once you’ve kind of gone through the vale and come out the other side. You never want to go back. Once you’ve sort of been and through that transition where you learn how test within development works and you start to do it. Then you understand the level of confidence that gives you, then you never want to go back to not having that. It’s the same sort of thing with a bunch of these other practices. A bunch of these other tools, a bunch of these other architectures, like why would I go back to this thing that like inflicts pain and fire on me on a regular basis when I could just do this other thing. You know on face it might seem a little bit more work or whatever in the beginning. The long term operational cost, the day-2 forward cost are considerably lower.

Coté:
I think that’s a pretty good place to wrap up. It sounds like, let me see if I’m setting this up correctly. It sounds like you will soon deliver the second part of sort of like Andrew’s cloud musings. The first one was sort of like at the BOSH level sort of configuration management camp. Then you’ll move up to the upper layers of speaking about like frameworks and things like that at Operability. Then eventually, will get to that other layer. Then we’ll have a little chat book.

Andrew Clay Shafer:
I’m just fortunate to be in a position to watch a bunch of these things happen. As a consequence of circumstances in my career, I basically got a front row seat to watch the velocity crowd build the big lab. That’s been going on for a while. Now, we’re just sort of emerging and taking. I feel like Pivotal’s mission right now is really taking all those patterns that we’re successfully building those kind of infrastructures, those kind of applications, and packaging in a way that it can be consumed by anyone who wants to consume it. That’s pretty exciting.

Coté:
It’s always fun to be working on a stack of opinions that are useful. It always reminds of the Thomas the Tank Engine thing. You just want to be a useful engine.

Andrew Clay Shafer:
I’m also been known for causing some confusion and delay but that’s-

Coté:
No. You don’t want to do that.

Andrew Clay Shafer:
That’s another topic.

Coté:
Confusion and delay. The worst defense on the Island of Sodor.

Andrew Clay Shafer:
Exactly.

Coté:
All right. With that, this has been another Pivotal conversation. We’ll I put some links into the relevant things on the show notes which you can find at pivotal.io/podcast. As I’m fond of saying, “If you like it plural you can put podcasts in there.” Either one will work. We’ll see everyone next time.

Andrew Clay Shafer:
Until next time.

About the Author

Biography

More Content by Coté
Previous
Case Study: Refactoring A Monolith Into A Cloud-Native App (Part 1)
Case Study: Refactoring A Monolith Into A Cloud-Native App (Part 1)

Migrating legacy, monolith apps on to Cloud-Native architectures is a challenge. In this post, we delve int...

Next
The Stoplights Metrics Dashboard for Cloud Foundry: Go or No Go
The Stoplights Metrics Dashboard for Cloud Foundry: Go or No Go

Pivotal’s Cloud Ops team provide production operation support for Pivotal Web Services, which offers Pivota...

Enter curious. Exit smarter.

Register Now